Discussion:
aur/solr: Unknown PGP key
(too old to reply)
Peter Nabbefeld
2018-07-26 21:01:53 UTC
Permalink
Raw Message
Hello,

when trying to install the solr package from aur, installation fails
because of an unknown PGP key ("051A0FAF76BC6507", according to comment
should be "Adrien Grand (CODE SIGNING KEY) <***@apache.org>").

Was this key removed from database for any reason, or did it just
change? Or does the package have security issues, and I shouldn't
install it?

Kind regards

Peter
Morten Linderud via arch-general
2018-07-26 21:07:09 UTC
Permalink
Raw Message
https://wiki.archlinux.org/index.php/Makepkg#Signature_checking
--
Morten Linderud
PGP: 9C02FF419FECBE16
Peter Nabbefeld
2018-07-26 21:45:32 UTC
Permalink
Raw Message
Post by Morten Linderud via arch-general
https://wiki.archlinux.org/index.php/Makepkg#Signature_checking
Thank You Morten! But I still have problems: From the wiki I understand,
I should set "keyserver-options auto-key-retrieve" in ~/.gnupg/gpg.conf,
which is set. IIUC, this should automate the magic to fetch the PGP key.
But building still fails. With aura, I've the option to acceppt the
package anyway, but I'd prefer to know the correct way.

Kind regards

Peter
Eli Schwartz via arch-general
2018-07-26 22:04:47 UTC
Permalink
Raw Message
Post by Peter Nabbefeld
Post by Morten Linderud via arch-general
https://wiki.archlinux.org/index.php/Makepkg#Signature_checking
Thank You Morten! But I still have problems: From the wiki I understand,
I should set "keyserver-options auto-key-retrieve" in ~/.gnupg/gpg.conf,
which is set. IIUC, this should automate the magic to fetch the PGP key.
But building still fails. With aura, I've the option to acceppt the
package anyway, but I'd prefer to know the correct way.
If you are getting "unknown key", then you need to ask yourself *why*
the key is unknown. Have you tried troubleshooting by downloading the
key using gpg --recv-keys manually?

I don't really see how this has anything to do with solr.
Post by Peter Nabbefeld
Was this key removed from database for any reason, or did it just
change? Or does the package have security issues, and I shouldn't
install it?
I've literally got no clue what you're trying to imply here. Database?
What database?
--
Eli Schwartz
Bug Wrangler and Trusted User
Peter Nabbefeld
2018-07-27 05:53:51 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
Post by Peter Nabbefeld
Post by Morten Linderud via arch-general
https://wiki.archlinux.org/index.php/Makepkg#Signature_checking
Thank You Morten! But I still have problems: From the wiki I understand,
I should set "keyserver-options auto-key-retrieve" in ~/.gnupg/gpg.conf,
which is set. IIUC, this should automate the magic to fetch the PGP key.
But building still fails. With aura, I've the option to acceppt the
package anyway, but I'd prefer to know the correct way.
If you are getting "unknown key", then you need to ask yourself *why*
the key is unknown. Have you tried troubleshooting by downloading the
key using gpg --recv-keys manually?
My fault. Tried the two gnupg example servers, but not the "alternative
key server" from wiki:
#keyserver hkp://keys.gnupg.net
#keyserver http://http-keys.gnupg.net

Should be:
keyserver pool.sks-keyservers.net

Probably this should not be mentiond as "alternative" key server, but
just be recommended for building PGP-signed packages.
Post by Eli Schwartz via arch-general
I don't really see how this has anything to do with solr.
Seems it's just my first AUR package using a PGP key.
Post by Eli Schwartz via arch-general
Post by Peter Nabbefeld
Was this key removed from database for any reason, or did it just
change? Or does the package have security issues, and I shouldn't
install it?
I've literally got no clue what you're trying to imply here. Database?
What database?
Just used as a synonym for a collection of several data records, no
matter if it's backed by some real database or just a text file, as this
doesn't really matter here.

Kind regards

Peter
Ralf Mardorf
2018-07-26 22:14:17 UTC
Permalink
Raw Message
Post by Peter Nabbefeld
Post by Morten Linderud via arch-general
https://wiki.archlinux.org/index.php/Makepkg#Signature_checking
Thank You Morten! But I still have problems: From the wiki I
understand, I should set "keyserver-options auto-key-retrieve" in
~/.gnupg/gpg.conf, which is set. IIUC, this should automate the magic
to fetch the PGP key. But building still fails. With aura, I've the
option to acceppt the package anyway, but I'd prefer to know the
correct way.
I can't comment on the Wiki, since I didn't read it. Note,
auto-key-retrieve means that any software automatically will
retrieve new keys from the default keyserver. An excerpt from the gpg
mangape, that belongs to auto-key-retrieve:

$ man gpg | grep '\"web bug\" l' -A1
Note that this option makes a "web bug" like behavior
possible. Keyserver or Web Key Directory operators can see which keys
you request, so by sending you a message signed by a brand new key
(which you naturally will not have on your local keyring), the operator
can tell both your IP address and the time when you verified the
signature.

I'm using an alias to manually add new keys:

$ grep gkey= .bashrc
alias gkey='gpg --keyserver hkp://pgp.uni-mainz.de --recv-keys'
Eli Schwartz via arch-general
2018-07-26 22:30:01 UTC
Permalink
Raw Message
Post by Ralf Mardorf
Post by Peter Nabbefeld
Thank You Morten! But I still have problems: From the wiki I
understand, I should set "keyserver-options auto-key-retrieve" in
~/.gnupg/gpg.conf, which is set. IIUC, this should automate the magic
to fetch the PGP key. But building still fails. With aura, I've the
option to acceppt the package anyway, but I'd prefer to know the
correct way.
I can't comment on the Wiki, since I didn't read it. Note,
auto-key-retrieve means that any software automatically will
retrieve new keys from the default keyserver. An excerpt from the gpg
$ man gpg | grep '\"web bug\" l' -A1
Note that this option makes a "web bug" like behavior
possible. Keyserver or Web Key Directory operators can see which keys
you request, so by sending you a message signed by a brand new key
(which you naturally will not have on your local keyring), the operator
can tell both your IP address and the time when you verified the
signature.
$ grep gkey= .bashrc
alias gkey='gpg --keyserver hkp://pgp.uni-mainz.de --recv-keys'
What does the "web bug" have to do with this discussion?
--
Eli Schwartz
Bug Wrangler and Trusted User
Ralf Mardorf
2018-07-26 22:50:12 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
What does the "web bug" have to do with this discussion?
It's a hint that not every user likes 'auto-key-retrieve', but instead
only manually retrieve keys, if it makes sense to the user to retrieve
a key. I don't see a valid reason, to e.g. retrieve the keys that
belong to an unknown signature of an email send via a mailing list,
just to get automatically keys when building something from AUR. I'm
surprised that you don't question the recommendation to use
'auto-key-retrieve' without providing this hint. I don't care much
about a privacy risk, but I don't see a reason to collect unneeded keys.
Could you explain why it's useful to collect each key that belongs to
an email signature, that is completely irrelevant to you, just to
automatically add keys that are required to build a package from AUR,
too?
Eli Schwartz via arch-general
2018-07-26 23:00:22 UTC
Permalink
Raw Message
Post by Ralf Mardorf
Post by Eli Schwartz via arch-general
What does the "web bug" have to do with this discussion?
It's a hint that not every user likes 'auto-key-retrieve', but instead
only manually retrieve keys, if it makes sense to the user to retrieve
a key. I don't see a valid reason, to e.g. retrieve the keys that
belong to an unknown signature of an email send via a mailing list,
just to get automatically keys when building something from AUR. I'm
surprised that you don't question the recommendation to use
'auto-key-retrieve' without providing this hint. I don't care much
about a privacy risk, but I don't see a reason to collect unneeded keys.
Ah, so, as I expected, it was just a standard prototypical offtopic
derail. Thanks for clarifying.
Post by Ralf Mardorf
Could you explain why it's useful to collect each key that belongs to
an email signature, that is completely irrelevant to you, just to
automatically add keys that are required to build a package from AUR,
too?
echo 'GNUPGHOME="$HOME"/.gnupg-makepkg' >>
"$HOME"/.config/pacman/makepkg.conf

Problem solved.
--
Eli Schwartz
Bug Wrangler and Trusted User
Ralph Corderoy
2018-07-27 07:10:30 UTC
Permalink
Raw Message
Hi Ralf,
Post by Eli Schwartz via arch-general
Post by Ralf Mardorf
It's a hint that not every user likes 'auto-key-retrieve', but
instead only manually retrieve keys, if it makes sense to the user
to retrieve a key.
Thanks, I found it on topic, given Peter explicitly mentioned the
option, and very helpful. I've added a note to the suggestion in
https://wiki.archlinux.org/index.php/GnuPG#Use_a_keyserver
Post by Eli Schwartz via arch-general
Post by Ralf Mardorf
I don't see a valid reason, to e.g. retrieve the keys that belong to
an unknown signature of an email send via a mailing list, just to
get automatically keys when building something from AUR.
Me neither, but
https://wiki.archlinux.org/index.php/Pacman/Package_signing doesn't
suggest `auto-key-retrieve'.
Post by Eli Schwartz via arch-general
Ah, so, as I expected, it was just a standard prototypical offtopic
derail. Thanks for clarifying.
Am I alone in finding Eli's comments unnecessarily sarcastic and
tiresome? I'm happy the Arch Linux community values a succinct and
frank exchange of views, but it could still be high signal without the
low-wit sarcasm by a few, and would be that bit nicer.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Ralf Mardorf
2018-07-27 23:28:45 UTC
Permalink
Raw Message
Post by Ralph Corderoy
Hi Ralf,
Post by Ralf Mardorf
It's a hint that not every user likes 'auto-key-retrieve', but
instead only manually retrieve keys, if it makes sense to the user
to retrieve a key.
Thanks, I found it on topic, given Peter explicitly mentioned the
option, and very helpful. I've added a note to the suggestion in
https://wiki.archlinux.org/index.php/GnuPG#Use_a_keyserver
Thank you Ralph, for editing the Wiki.
Post by Ralph Corderoy
Post by Ralf Mardorf
I don't see a valid reason, to e.g. retrieve the keys that belong to
an unknown signature of an email send via a mailing list, just to
get automatically keys when building something from AUR.
Me neither, but
https://wiki.archlinux.org/index.php/Pacman/Package_signing doesn't
suggest `auto-key-retrieve'.
I didn't read all related Wiki pages, but seemingly non, including
https://wiki.archlinux.org/index.php/makepkg mention Eli's hint, to use

echo 'GNUPGHOME="$HOME"/.gnupg-makepkg' >> "$HOME"/.config/pacman/makepkg.conf

Fortunately the manpage does.

$ man makepkg | grep GNUPGHOME
GNUPGHOME="/path/to/directory"

I'm short in time and apart from this I'm uncertain, if it's worth to
add this to the Arch Wiki.

Regards,
Ralf
Ralf Mardorf
2018-07-27 23:38:48 UTC
Permalink
Raw Message
JFTR by accident Ralph wrote "Eli wrote:", while it should read "Ralf
wrote:". Most likely he selected my reply quoted by Eli's mail, before
invoking the reply to Eli's mail. My apologies, I also didn't notice
this, when I replied to Ralph's mail, so I didn't fix it. A thing like
that could happen ;).
Ralf Mardorf
2018-07-27 23:41:12 UTC
Permalink
Raw Message
Post by Ralf Mardorf
JFTR by accident Ralph wrote "Eli wrote:", while it should read "Ralf
wrote:". Most likely he selected my reply quoted by Eli's mail, before
invoking the reply to Eli's mail. My apologies, I also didn't notice
this, when I replied to Ralph's mail, so I didn't fix it. A thing like
that could happen ;).
Oops, it were nested quotes, my bad.
Ralph Corderoy
2018-07-28 09:13:15 UTC
Permalink
Raw Message
Hi Ralf,
Post by Ralf Mardorf
I didn't read all related Wiki pages, but seemingly non, including
https://wiki.archlinux.org/index.php/makepkg mention Eli's hint, to use
echo 'GNUPGHOME="$HOME"/.gnupg-makepkg' >> "$HOME"/.config/pacman/makepkg.conf
Fortunately the manpage does.
$ man makepkg | grep GNUPGHOME
GNUPGHOME="/path/to/directory"
It mentions that environment variable, defined by gpg(1), but
makepkg.conf(5) says

Configuration options for makepkg are stored in makepkg.conf.
This file is sourced so you can include any special compiler flags
you wish to use. This is helpful when building for different
architectures or with different optimizations. However, only the
variables described below are exported to the build environment.

`GNUPGHOME' isn't described so I wouldn't expect it to be exported. I
suppose it's stated as being `sourced', and makepkg(1) says it's a
script, and looking at /usr/bin/makepkg shows it's a bash script, so you
could whack an `export' in makepkg.conf too, but it would be nice if
makepkg.conf(5) gave explicit approval to arbitrary environment
variables if that's intended.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Eli Schwartz via arch-general
2018-07-29 03:02:41 UTC
Permalink
Raw Message
Post by Ralph Corderoy
Hi Ralf,
Post by Ralf Mardorf
I didn't read all related Wiki pages, but seemingly non, including
https://wiki.archlinux.org/index.php/makepkg mention Eli's hint, to use
echo 'GNUPGHOME="$HOME"/.gnupg-makepkg' >> "$HOME"/.config/pacman/makepkg.conf
It's just common sense IMHO. It's not even remotely makepkg-specific.
This is just basic "using different gnupg keyrings for different
purposes", the only thing special about putting it in makepkg.conf
instead of creating a shell alias:

alias makepkg="GNUPGHOME="$HOME"/.gnupg-makepkg makepkg"

is, well, to take advantage of the fact that makepkg.conf is a
bash-compatible configuration file and save on the aliases cluttering up
your shell environment. (Also I usually have makepkg aliased to
something else, that being my pacman.git copy which I hack on.)
Post by Ralph Corderoy
Post by Ralf Mardorf
Fortunately the manpage does.
$ man makepkg | grep GNUPGHOME
GNUPGHOME="/path/to/directory"
It mentions that environment variable, defined by gpg(1), but
makepkg.conf(5) says
Configuration options for makepkg are stored in makepkg.conf.
This file is sourced so you can include any special compiler flags
you wish to use. This is helpful when building for different
architectures or with different optimizations. However, only the
variables described below are exported to the build environment.
`GNUPGHOME' isn't described so I wouldn't expect it to be exported. I
suppose it's stated as being `sourced', and makepkg(1) says it's a
script, and looking at /usr/bin/makepkg shows it's a bash script, so you
could whack an `export' in makepkg.conf too, but it would be nice if
makepkg.conf(5) gave explicit approval to arbitrary environment
variables if that's intended.
The man page is entirely correct. The file is sourced, and anything
sourced in there is, well, sourced, regardless of how "arbitrary" it is.

To export something is completely different, how many variables there
will desperately need to be marked as something inheritable by child
processes?

makepkg does not export anything on its own, except for the minimal
things which actually need to be, which means compiler things like
{C,CXX,LD,MAKE}FLAGS, CHOST, DISTCC_HOSTS

Exporting e.g. BUILDDIR could be quite harmful and is in fact the reason
why some packages (which depressingly use this generic name as an
internal Makefile constant) will not build correctly using yaourt.

GNUPGHOME is definitively unlikely to be the same sort of issue... but
that's still no reason to declare random things as officially supported
and then source them just in case.

That being said, it is indeed a good point that I was incorrect and
you'd need to:

echo 'export GNUPGHOME="$HOME"/.gnupg-makepkg' >>
"$HOME"/.config/pacman/makepkg.conf

in order to make this work properly.

I consider this to be eminently reasonable without further modifications
to makepkg.conf(5), since it is described as being sourced after all.
--
Eli Schwartz
Bug Wrangler and Trusted User
Ralph Corderoy
2018-07-30 16:23:53 UTC
Permalink
Raw Message
Hi Eli,
Post by Eli Schwartz via arch-general
Post by Ralph Corderoy
Post by Ralf Mardorf
Fortunately the manpage does.
$ man makepkg | grep GNUPGHOME
GNUPGHOME="/path/to/directory"
It mentions that environment variable, defined by gpg(1), but
makepkg.conf(5) says
Configuration options for makepkg are stored in makepkg.conf.
This file is sourced so you can include any special compiler
flags you wish to use. This is helpful when building for
different architectures or with different optimizations.
However, only the variables described below are exported to the
build environment.
`GNUPGHOME' isn't described so I wouldn't expect it to be exported.
I suppose it's stated as being `sourced', and makepkg(1) says it's a
script, and looking at /usr/bin/makepkg shows it's a bash script, so
you could whack an `export' in makepkg.conf too, but it would be
nice if makepkg.conf(5) gave explicit approval to arbitrary
environment variables if that's intended.
The man page is entirely correct. The file is sourced, and anything
sourced in there is, well, sourced, regardless of how "arbitrary" it is.
I'll be more clear.

makepkg(1) says `makepkg is a script'.
It doesn't say what kind of script, e.g. sh(1), bash(1), ...

makepkg.conf(5) says `This file is sourced',
but again doesn't state the language.
Post by Eli Schwartz via arch-general
makepkg does not export anything on its own, except for the minimal
things which actually need to be, which means compiler things like
{C,CXX,LD,MAKE}FLAGS, CHOST, DISTCC_HOSTS
Right, that add up to thirty-odd variables. I wasn't arguing that
`GNUPGHOME' should be magically exported just be being assigned in
makepkg.conf, but stating it won't be exported because, quite
reasonably, it isn't in makepkg.conf(5)'s list. Thus some method of
exporting it would be required.

But makepkg.conf(5) just shows variable assignments because it's
explicit they'll all be exported so the export syntax for this unknown
language isn't shown.

Besides, it's a lot more clear to have makepkg.conf(5) say it's bash(1)
syntax and any bash code is acceptable, than see it's a list of
`VAR=value' and wonder if deviating from that would be fragile and break
in the future even if it's OK today. mkinitcpio.conf(5) has the same
issue.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Eli Schwartz via arch-general
2018-07-30 17:10:10 UTC
Permalink
Raw Message
Post by Ralph Corderoy
I'll be more clear.
makepkg(1) says `makepkg is a script'.
It doesn't say what kind of script, e.g. sh(1), bash(1), ...
makepkg.conf(5) says `This file is sourced',
but again doesn't state the language.
Well, on the other hand the actual makepkg.conf contains a *bash*
shebang. :)

Anyway my default rule when a file is "sourced" is to stick with the
lowest common denominator, that is to say, POSIX sh, since it would
therefore work regardless.

However, in this case makepkg.conf lists a number of options that are
part of makepkg.conf's formal API, which are represented by shell
arrays, which indicates that POSIX sh is insufficient and you need bash.
One who notices this could easily infer without leaving the
configuration file, that it is bash.

I'll ignore zsh on the grounds that no one *actually* writes programs in
zsh...

...

So, two points that definitively confirm it is bash, and a
guaranteed-safe fallback in sh for people who don't notice this.
Post by Ralph Corderoy
Right, that add up to thirty-odd variables. I wasn't arguing that
`GNUPGHOME' should be magically exported just be being assigned in
makepkg.conf, but stating it won't be exported because, quite
reasonably, it isn't in makepkg.conf(5)'s list. Thus some method of
exporting it would be required.
But makepkg.conf(5) just shows variable assignments because it's
explicit they'll all be exported so the export syntax for this unknown
language isn't shown.
It is, technically, a lie that they'll be exported, since many are not
but it doesn't specify what it actually means there and basically
implies that everything on that page is in fact exported to all
subprocesses.

Although I'm not sure if this generally matters as the ones used for
internal state won't surprise people when some Makefile does not honor
them, and moreover, half of them are arrays which aren't variables and
cannot be exported as environment *variables*.
Post by Ralph Corderoy
Besides, it's a lot more clear to have makepkg.conf(5) say it's bash(1)
syntax and any bash code is acceptable, than see it's a list of
`VAR=value' and wonder if deviating from that would be fragile and break
in the future even if it's OK today. mkinitcpio.conf(5) has the same
issue.
Patches welcome! Developers often do not realize that what seems obvious
to us (cf. my above inferences regarding the language syntax) are
non-obvious to others. When confusion arises, this is a good opportunity
to get outside perspective on the matter (and, coincidentally, a sneaky
way to trick people into becoming contributors :D).
--
Eli Schwartz
Bug Wrangler and Trusted User
Ralph Corderoy
2018-07-30 17:34:58 UTC
Permalink
Raw Message
Hi Eli,
Post by Eli Schwartz via arch-general
I'll ignore zsh on the grounds that no one *actually* writes programs
in zsh...
No, true. But tcl(1) has `source filename'. :-)
Post by Eli Schwartz via arch-general
Patches welcome!
...
Post by Eli Schwartz via arch-general
(and, coincidentally, a sneaky way to trick people into becoming
contributors :D).
Quite right, I need to get better organised and try to contribute.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Eli Schwartz via arch-general
2018-07-29 03:01:22 UTC
Permalink
Raw Message
Post by Ralf Mardorf
$ man makepkg | grep GNUPGHOME
GNUPGHOME="/path/to/directory"
I'm short in time and apart from this I'm uncertain, if it's worth to
add this to the Arch Wiki.
I see no reason to duplicate even more gnupg documentation on the
makepkg wiki page. Anyway, it's indicated pretty clearly in the manpage
already.
--
Eli Schwartz
Bug Wrangler and Trusted User
Ralf Mardorf
2018-07-29 04:19:16 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
Post by Ralf Mardorf
$ man makepkg | grep GNUPGHOME
GNUPGHOME="/path/to/directory"
I'm short in time and apart from this I'm uncertain, if it's worth to
add this to the Arch Wiki.
I see no reason to duplicate even more gnupg documentation on the
makepkg wiki page. Anyway, it's indicated pretty clearly in the manpage
already.
While I was uncertain, I can only agree with that now. Keep in mind, I
anyway import keys knowingly, manually. Try to understand that what you
consider trolling, a rant, off-topic, is just a hint. There's no need
to read a Wiki, if you know something, as I do in this case.

Have you ever take care about the content of your replies? You spend
more than 50% of the content by many replies from you, also for topics
I'm completely not involved, to degrade skills of other. I bet that a
lot of us absolutely don't care, if they have more or less skills than
another. Mind your attitude. Why is it that important to you to
comment everything somebody sends to the list, that might not apply to
whatsoever policy? You can't ignore it? If so, you only hurt yourself.
With your childish comments you don't hurt or tutor anybody.
Eli Schwartz via arch-general
2018-07-29 03:01:07 UTC
Permalink
Raw Message
Post by Ralph Corderoy
Thanks, I found it on topic, given Peter explicitly mentioned the
option, and very helpful. I've added a note to the suggestion in
https://wiki.archlinux.org/index.php/GnuPG#Use_a_keyserver
Yes, clearly jumping down the throat of anyone who dares mention they
use such an option is super useful, because "it's fair game, they
mentioned the option".

Because no one ever, like, reads the manpage to understand what they're
actually doing or why it helps.

Oh well, at least you unlike Mr. Mardorf actually read the wiki page and
are therefore qualified to point out that it suggests using an option
without also giving the other side of the argument. This is a helpful
way to approach things, thank you for noticing and for fixing it. :)

Had this been the tone of conversation from the start I would have had
no issues whatsoever.

This is entirely different from "omg someone uses auto-key-retrieve
quickly let me rant about how it is evil".
Post by Ralph Corderoy
Am I alone in finding Eli's comments unnecessarily sarcastic and
tiresome? I'm happy the Arch Linux community values a succinct and
frank exchange of views, but it could still be high signal without the
low-wit sarcasm by a few, and would be that bit nicer.
Some people make me more exasperated than others, usually when they make
a trend of consistently unhelpful commentary.

I'm generally okay with people who don't know a lot, and in fact I hang
out in #archlinux-newbie and #archlinux-classroom on Freenode, helping
to guide new users when I have the time.

It's an entirely different matter when I see something which I don't
regard as reasonable at any skill level.

I consider this to be compatible with the Arch Linux philosophy of
valuing common sense, pragmatism, and users with a do-it-yourself
attitude who try to understand how things work... but does not have any
goal, either implicit or explicit, of valuing bikesheds, valueless
discussion, help vampires, trolls, the enforcement of foreign ideologies
(FSF-style freedom is always a popular rallying point), and others.

Your subsequent response about the wiki being lacking was useful,
high-signal content! That does not absolve the person who jumps into the
conversation with "I can't comment on the Wiki, since I didn't read it"
from being decidedly low-signal, *continuing what I feel to be a general
trend on a personal level*, and thus fair game for my sarcasm, "low-wit"
or not.

For I consider that to have been trolling. The fact that it had a useful
result was entirely accidental and surprising.
--
Eli Schwartz
Bug Wrangler and Trusted User
Ralf Mardorf
2018-07-29 03:30:08 UTC
Permalink
Raw Message
"omg someone uses auto-key-retrieve quickly let me rant about how it
is evil"
You are polemic. Netiquette requires to assume good faith. I didn't
rant at all, I just informed. You are now trying to mitigate your
pitful attitude by continuing snideness. You seemingly need to sent
such an off-topic constant howling to the Arch mailing lists, to
enhance your personality. I am sorry for you! Most of us have a life
apart from computers, which clearly helps to feel good without the need
of smug self-satisfaction.
Ralph Corderoy
2018-07-30 16:24:24 UTC
Permalink
Raw Message
Hi Eli,
Post by Eli Schwartz via arch-general
Yes, clearly jumping down the throat of anyone who dares mention they
use such an option is super useful, because "it's fair game, they
mentioned the option".
Peter mentioned auto-key-retrieve and in return got

Note, auto-key-retrieve means that any software automatically will
retrieve new keys from the default keyserver.

followed by a pertinent extract of a man page from Ralf.
That isn't `jumping down the throat'.
Post by Eli Schwartz via arch-general
Had this been the tone of conversation from the start I would have had
no issues whatsoever.
It was Ralf's first post on the thread AFAICS.
Post by Eli Schwartz via arch-general
This is entirely different from "omg someone uses auto-key-retrieve
quickly let me rant about how it is evil".
There was no rant. When you asked why pointing out auto-key-retrieve's
side effects were relevant, Ralf explained his reasoning and politely
asked you to explain yours.
Post by Eli Schwartz via arch-general
Some people make me more exasperated than others, usually when they
make a trend of consistently unhelpful commentary.
Then perhaps user support isn't your forte? :-)
Personally, for me, its those that won't learn to fish that annoy.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Ralf Mardorf
2018-07-26 22:33:22 UTC
Permalink
Raw Message
With aura, I've the option to acceppt the package anyway, but I'd
prefer to know the correct way.
'makepkg' provides a lot of 'skip' options
Loading...