Discussion:
Suppressing specific pacman warnings
(too old to reply)
João Miguel via arch-general
2017-04-01 15:14:28 UTC
Permalink
Raw Message
Hello,

I have some unofficial repos added in pacman.conf, and at times use ABS
and the AUR, so I often get messages like this:

# LANG=C pacman -Syu
...
:: Starting full system upgrade...
warning: udevil: local (0.4.4-2) is newer than community (0.4.4-1)
...(10 messages from unofficial repos)...

First of all, why is this a warning? What is the problem of me having a
newer version of a package than the repository? --quiet does not help. I
could do

# pacman -Syu 2>/dev/null

but this supresses *all* warnings. Also if I need to hold ignore a few
packages, I get this (which actually makes more sense as a warning):

warning: haskell-src-exts: ignoring package upgrade (1.17.1-8 => 1.18.2-4)

which I know already, since I'm the one who put it IgnorePkg. I looked
in the manpage for pacman.conf and also found nothing to quiet specific
warnings like this. Could they at least be less verbose? Say, in one line:

warning: ignoring (42) package updates (for nvidia, nvidia-dkms,
haskell-src-exts, ...)

I found this old bug report (https://bugs.archlinux.org/task/31594)
regarding this, but there's no decision about it.

I'd like there to be an option to quiet these, possibly in pacman.conf:

QuietWarning = NewerThanRepo | IgnoredUpdate | ...

What do you think? Thanks in advance for any suggestions.
João Miguel
Guus Snijders via arch-general
2017-04-01 16:13:59 UTC
Permalink
Raw Message
Op 1 apr. 2017 17:14 schreef "João Miguel via arch-general" <
arch-***@archlinux.org>:

Hello,

I have some unofficial repos added in pacman.conf, and at times use ABS
and the AUR, so I often get messages like this:

# LANG=C pacman -Syu
...
:: Starting full system upgrade...
warning: udevil: local (0.4.4-2) is newer than community (0.4.4-1)
...(10 messages from unofficial repos)...


You could use basic shell redirection;

pacman -Syu 2>&1 | egrep -v "is newer than"

The example uses egrep because that is easy with multiple patterns
(seperated with pipe symbols).

For real ease, test a few cases, then make a function of it.

Mvg, Guus Snijders
João Miguel via arch-general
2017-04-03 13:39:09 UTC
Permalink
Raw Message
Post by Guus Snijders via arch-general
Op 1 apr. 2017 17:14 schreef "João Miguel via arch-general" <
Hello,
I have some unofficial repos added in pacman.conf, and at times use ABS
# LANG=C pacman -Syu
...
:: Starting full system upgrade...
warning: udevil: local (0.4.4-2) is newer than community (0.4.4-1)
...(10 messages from unofficial repos)...
You could use basic shell redirection;
pacman -Syu 2>&1 | egrep -v "is newer than"
Thanks for the example, I was considering doing something on those
lines, but then I thought maybe other people would also like an option
to do it, or that it would make more sense.

Also, that piping disables some interactivity. Colour can be shown with
--color=always, but the progress bars are gone.

Regards,
João Miguel

P.S.: I had sent this but forgot to CC arch-general
Eli Schwartz via arch-general
2017-04-02 06:02:30 UTC
Permalink
Raw Message
Post by João Miguel via arch-general
First of all, why is this a warning? What is the problem of me having a
newer version of a package than the repository? --quiet does not help. I
could do
Why would a mismatch between what is expected and what is actually
there, *not* be something to warn the user about?
Post by João Miguel via arch-general
# pacman -Syu 2>/dev/null
but this supresses *all* warnings. Also if I need to hold ignore a few
warning: haskell-src-exts: ignoring package upgrade (1.17.1-8 => 1.18.2-4)
which I know already, since I'm the one who put it IgnorePkg. I looked
in the manpage for pacman.conf and also found nothing to quiet specific
warning: ignoring (42) package updates (for nvidia, nvidia-dkms,
haskell-src-exts, ...)
This would result in some extremely long lines, but I am not really sure
why you have 42 packages ignored anyway. So I am not entirely sure how
much this would help your case.
Post by João Miguel via arch-general
I found this old bug report (https://bugs.archlinux.org/task/31594)
regarding this, but there's no decision about it.
QuietWarning = NewerThanRepo | IgnoredUpdate | ...
What do you think? Thanks in advance for any suggestions.
João Miguel
If pacman is going to output such messages in the first place, offering
to ignore them strikes me as unwise.

The whole reason for outputting such messages to begin with, IMHO, is to
alert the user that something unexpected (packages from the future) is
going on, or they are performing a risky action (ignoring packages).

It is hardly a huge burden to see them, since after all you are looking
at the output of an interactive program which already emits lots of
other information you are expected to read, some of which is
interspersed with stuff you don't really have to pay attention to
(progress bars).
In short, important information is important, and should be seen...

...

Though, personally, if I fork a repo package I add it to my [custom]
repo which has priority. So I never see the state of the official repos.
--
Eli Schwartz
João Miguel via arch-general
2017-04-02 22:17:45 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
Post by João Miguel via arch-general
First of all, why is this a warning? What is the problem of me having a
newer version of a package than the repository? --quiet does not help. I
could do
Why would a mismatch between what is expected and what is actually
there, *not* be something to warn the user about?
I mean, why is it unexpected? Is it at all unexpected that a package I
ignored is being ignored? (see below for newer versions)
Post by Eli Schwartz via arch-general
Post by João Miguel via arch-general
(...)
warning: ignoring (42) package updates (for nvidia, nvidia-dkms,
haskell-src-exts, ...)
This would result in some extremely long lines, but I am not really sure
why you have 42 packages ignored anyway. So I am not entirely sure how
much this would help your case.
42 was an example, I don't have anywhere near that number of packages
ignored. The actual number in my case varies between 0 and 15 (currently
3).
Post by Eli Schwartz via arch-general
Post by João Miguel via arch-general
I found this old bug report (https://bugs.archlinux.org/task/31594)
regarding this, but there's no decision about it.
Note: if this is really not worth anyone's time, this should be closed
as WONTFIX.
Post by Eli Schwartz via arch-general
Post by João Miguel via arch-general
QuietWarning = NewerThanRepo | IgnoredUpdate | ...
(...)
If pacman is going to output such messages in the first place, offering
to ignore them strikes me as unwise.
The whole reason for outputting such messages to begin with, IMHO, is to
alert the user that something unexpected (packages from the future) is
But when would there be packages from the future!? I think if pacman
finds I have a more recent version than the repos do, the obvious reason
is that I got it from somewhere else. When would I have a higher version
except for that reason?
Post by Eli Schwartz via arch-general
going on, or they are performing a risky action (ignoring packages).
I know it is unsupported, but I don't need to be told that it is risky
every time in such a verbose manner.
Post by Eli Schwartz via arch-general
It is hardly a huge burden to see them, since after all you are looking
at the output of an interactive program which already emits lots of
other information you are expected to read, some of which is
interspersed with stuff you don't really have to pay attention to
(progress bars).
In short, important information is important, and should be seen...
What I'm disputing here is precisely that information being important.
Progress bars are important sometimes, and can be disabled with
--noprogressbar. I'd say that option is less important (and is already
implicit with, say, piping).
Post by Eli Schwartz via arch-general
...
Though, personally, if I fork a repo package I add it to my [custom]
repo which has priority. So I never see the state of the official repos.
Thank you, that does sound like a nice idea! (to anyone interested,
found some information here:
https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#Custom_local_repository)
João Miguel
Allan McRae
2017-04-02 22:25:16 UTC
Permalink
Raw Message
Post by João Miguel via arch-general
Post by João Miguel via arch-general
I found this old bug report (https://bugs.archlinux.org/task/31594)
regarding this, but there's no decision about it.
Note: if this is really not worth anyone's time, this should be closed
as WONTFIX.
That bug is about a completely different issue...

Your issue is a WONTFIX.

A
João Miguel via arch-general
2017-04-03 13:55:28 UTC
Permalink
Raw Message
Post by Allan McRae
Post by João Miguel via arch-general
Post by João Miguel via arch-general
I found this old bug report (https://bugs.archlinux.org/task/31594)
regarding this, but there's no decision about it.
Note: if this is really not worth anyone's time, this should be closed
as WONTFIX.
That bug is about a completely different issue...
Ah, you're right, mine is before dependency resolution.
Post by Allan McRae
Your issue is a WONTFIX.
Well, at least now I know.

João Miguel
Guus Snijders via arch-general
2017-04-04 08:08:42 UTC
Permalink
Raw Message
Op 3 apr. 2017 15:55 schreef "João Miguel via arch-general" <
Post by Allan McRae
Post by João Miguel via arch-general
Post by João Miguel via arch-general
I found this old bug report (https://bugs.archlinux.org/task/31594)
regarding this, but there's no decision about it.
Note: if this is really not worth anyone's time, this should be closed
as WONTFIX.
That bug is about a completely different issue...
Ah, you're right, mine is before dependency resolution.
Post by Allan McRae
Your issue is a WONTFIX.
Well, at least now I know.


I think Ely Swartz gave the best option;
Use a custom repo for the non-standard pkg's and give it priority.

Mvg, Guus Snijders
João Miguel via arch-general
2017-04-04 22:02:57 UTC
Permalink
Raw Message
Post by Guus Snijders via arch-general
(...)
I think Ely Swartz gave the best option;
Use a custom repo for the non-standard pkg's and give it priority.
Mvg, Guus Snijders
I agree, and the best part is that one can make it public so that the
everyone else can enjoy the pre-compiled packages (because this isn't
Gentoo). I'll add mine to the unofficial repos soon.

Thank you for your time. Have a /bin/repo-elephant:
__
'. \
'- \
/ /_ .---.
/ | \\,.\/--.// )
| \// )/ /
\ ' ^ ^ / )____.----.. 6
'.____. .___/ \._)
.\/. )
'\ /
_/ \/ ). ) (
/# .! | /\ /
\ C// # /'-----''/ # /
. 'C/ | | | | |mrf ,
\), .. .'OOO-'. ..'OOO'OOO-'. ..\(,

All the best,
João Miguel
SanskritFritz via arch-general
2017-04-05 08:44:05 UTC
Permalink
Raw Message
On Wed, Apr 5, 2017 at 12:02 AM, João Miguel via arch-general <
Post by João Miguel via arch-general
Post by Guus Snijders via arch-general
(...)
I think Ely Swartz gave the best option;
Use a custom repo for the non-standard pkg's and give it priority.
Mvg, Guus Snijders
I agree, and the best part is that one can make it public so that the
everyone else can enjoy the pre-compiled packages (because this isn't
Gentoo). I'll add mine to the unofficial repos soon.
I would like to maintain a custom repo too. However I don't have a public
server and couldn't find suitable free storage. I tried Sourceforge but
when I want to register a new project, it asks for my phone number.
Do you guys know of any good public storage where I could store my custom
repo for the public?
Bartłomiej Piotrowski
2017-04-05 09:39:16 UTC
Permalink
Raw Message
Post by SanskritFritz via arch-general
On Wed, Apr 5, 2017 at 12:02 AM, João Miguel via arch-general <
Post by João Miguel via arch-general
Post by Guus Snijders via arch-general
(...)
I think Ely Swartz gave the best option;
Use a custom repo for the non-standard pkg's and give it priority.
Mvg, Guus Snijders
I agree, and the best part is that one can make it public so that the
everyone else can enjoy the pre-compiled packages (because this isn't
Gentoo). I'll add mine to the unofficial repos soon.
I would like to maintain a custom repo too. However I don't have a public
server and couldn't find suitable free storage. I tried Sourceforge but
when I want to register a new project, it asks for my phone number.
Do you guys know of any good public storage where I could store my custom
repo for the public?
Vultr offers a VPS for 2.50$/month. I doubt there is anything cheaper.

Bartłomiej
Ben Oliver via arch-general
2017-04-05 09:56:39 UTC
Permalink
Raw Message
https://lowendbox.com/ is a good place to shop around on.
João Miguel via arch-general
2017-04-05 10:08:27 UTC
Permalink
Raw Message
Post by SanskritFritz via arch-general
On Wed, Apr 5, 2017 at 12:02 AM, João Miguel via arch-general <
Post by João Miguel via arch-general
Post by Guus Snijders via arch-general
(...)
I think Ely Swartz gave the best option;
Use a custom repo for the non-standard pkg's and give it priority.
Mvg, Guus Snijders
I agree, and the best part is that one can make it public so that the
everyone else can enjoy the pre-compiled packages (because this isn't
Gentoo). I'll add mine to the unofficial repos soon.
I would like to maintain a custom repo too. However I don't have a public
server (...)
Since you probably won't get much traffic and most ISPs have high limits
for bandwidth anyway, you can do port forwarding on you router to an old
PC or low-powered computer to work as a server and use something like
https://freedns.afraid.org/ to create a DNS A record to your IP. Total
cost if you already have an old computer: 0. And you get to learn how to
set up server-y things!

Hope this helps,
João Miguel

Oon-Ee Ng via arch-general
2017-04-03 02:40:55 UTC
Permalink
Raw Message
On Mon, Apr 3, 2017 at 6:17 AM, João Miguel via arch-general <
Post by João Miguel via arch-general
Post by Eli Schwartz via arch-general
Post by João Miguel via arch-general
QuietWarning = NewerThanRepo | IgnoredUpdate | ...
(...)
If pacman is going to output such messages in the first place, offering
to ignore them strikes me as unwise.
The whole reason for outputting such messages to begin with, IMHO, is to
alert the user that something unexpected (packages from the future) is
But when would there be packages from the future!? I think if pacman
finds I have a more recent version than the repos do, the obvious reason
is that I got it from somewhere else. When would I have a higher version
except for that reason?
Why is that 'the obvious reason'? Another (arguably more common) reason is
partial repo syncs, or some problem with a repo (as pacman does automatic
fall-back when a repo cannot be contacted). In that situation a user
really does need to know that some packages on this system appear to be
from the future (relative to the currently synced repo information) as this
could have a fairly large impact on the system running at all.

And if you're installing newer versions yourself, it's not really hard to
read past it.... way too many users do that anyway,
Loading...