[gentoo-dev] [PATCH v2] font.eclass: Don't assign FONT_S in global scope, allow an array.
Accessing ${S} in global scope is not allowed by PMS, therefore remove
the global variable assignment of FONT_S which uses it. Add a fallback
to ${S} in font_src_install() instead.
Allow FONT_S to be an array, if there are multiple directories.
Support for whitespace-separated lists will be kept for some time,
and a QA warning will be shown.
Die if pushd or popd fails.
Closes: https://bugs.gentoo.org/613108
Closes: https://bugs.gentoo.org/709578
Signed-off-by: Ulrich Müller
---
v2: Quote pattern substitution, fix die message
eclass/font.eclass | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/eclass/font.eclass b/eclass/font.eclass
index 1287f2273454..6b50c28890a1 100644
--- a/eclass/font.eclass
+++ b/eclass/font.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2019 Gentoo Authors
+# Copyright 1999-2020 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: font.eclass
@@ -25,10 +25,10 @@ EXPORT_FUNCTIONS pkg_setup src_install pkg_postinst
pkg_postrm
FONT_SUFFIX=${FONT_SUFFIX:-}
# @ECLASS-VARIABLE: FONT_S
-# @REQUIRED
+# @DEFAULT_UNSET
# @DESCRIPTION:
-# Space delimited list of directories containing the fonts.
-FONT_S=${FONT_S:-${S}}
+# Directory containing the fonts. If unset, ${S} is used instead.
+# Can also be an array of several directories.
# @ECLASS-VARIABLE: FONT_PN
# @DESCRIPTION:
@@ -159,27 +159,39 @@ font_pkg_setup() {
font_src_install() {
local dir suffix commondoc
- set -- ${FONT_S:-${S}}
- if [[ $# -gt 1 ]]; then
- # if we have multiple FONT_S elements then we want to recreate
the dir
- # structure
+ if [[ $(declare -p FONT_S) == "declare -a "* ]]; then
+ # recreate the directory structure if FONT_S is an array
+ for dir in "${FONT_S[@]}"; do
+ pushd "${dir}" > /dev/null || die "pushd ${dir} failed"
+ insinto "${FONTDIR}/${dir#"${S}"}"
+ for suffix in ${FONT_SUFFIX}; do
+ doins *.${suffix}
+ done
+ font_xfont_config "${dir}"
+ popd > /dev/null || die
+ done
+ elif [[ ${FONT_S/ } != "${FONT_S}" ]]; then
+ # backwards compatibility code, can be removed after 2021-02-14
+ eqawarn "Using a space-separated list for FONT_S is deprecated."
+ eqawarn "Use a bash array instead if there are multiple
directories."
for dir in ${FONT_S}; do
- pushd "${dir}" > /dev/null
+ pushd "${dir}" > /dev/null || die "pushd ${dir} failed"
insinto "${FONTDIR}/${dir//${S}/}"
for suffix in ${FONT_SUFFIX}; do
doins *.${suffix}
done
font_xfont_config "${dir}"
- popd > /dev/null
+ popd > /dev/null || die
done
else
- pushd "${FONT_S}" > /dev/null
+ pushd "${FONT_S:-${S}}" > /dev/null \
+ || die "pushd ${FONT_S:-${S}} failed"
insinto "${FONTDIR}"
for suffix in ${FONT_SUFFIX}; do
doins *.${suffix}
done
font_xfont_config
- popd > /dev/null
+ popd > /dev/null || die
fi
font_fontconfig
--
2.25.0
signature.asc
Description: PGP signature
Re: [gentoo-dev] Changes made by acct-* ebuilds
On 14/02/20 19:48, Vadim A. Misbakh-Soloviov wrote: >> And now you're changing the subject. You've just claimed that *your* >> user's group ownership will be overwritten and when challenged you >> present the case of *system* user's group ownership being overwritten. > Actually, he showed the rewrite of **system** user (that was modified > locally). > > And, as it already mentioned above, this behaviour violates Gentoo Philosophy > of not pretending to be smarter than user and don't dictate them a way to go. > > So, if the problem is only in the existance of the bug, I can create it > tomorrow morning. > But it would be great to know that it wont be closed in a minute after with > "WONTFIX, works as expected". > > Also, as already stated, changing the stuff that was modified by user is > **prohibited**. > > P.S. I don't care about your relations with whissi, but let's back to the > topic: > > [big red letters] > We should **NEVER** ever rewrite any system configuration made by local > system > administrator (call it "user" or whatever). Dixi. > [/big red letters] > > Modification of system users and groups are also covered by that user. > > So, we, actually don't need any changes to disable acct-* things at all and > make users to manage all the things by themselves. > We need a change that will prevent any changes over **already existing** user. > > I think we should make it in a manner like: > 1) when we install acct-pkg for a first time - CONFIG_PROTECT changes, and > let > user to review. > 2) when we **reinstall** same package - do **nothing**. Although, I'm not > sure > here: > on the one hand, why should we bother users by merging changes they already > did before, > on the other hand, it can be useful way to reset to defaults in case if "all > this stuff is screwed up". > 3) when we upgrade acct-package (assuming there was changes) - only allow > "positive" changes (group additions), but not negative (dropiing groups), and > anyway CONFIG_PROTECT all the changes. > > > Well, there is also "kludgy way": does not globally reimplement anything, but: > 1) force CFGPROTECT > 2) perform a "light" modification to only perform "positive" modifications > (see above) on users/groups, but no "negatives". > It will anyway fix the both issues Whissi and OP had. > There is a filthy hack which works around all this nonsense .. throw all acct-* packages in a Package.Provided entry, and mask installation of any other versions .. *runs and hides* signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Saturday, 15 February 2020 3:14:55 AM AEDT Matt Turner wrote: > On Fri, Feb 14, 2020 at 12:31 AM Sam Jorna (wraeth) wrote: > > In this instance, at least two people (myself included) have drawn an > > impression that led them to voice their concern in some way (I'm unsure if > > mpagano was voicing concern or just agreeing with the general concept). > > Maybe we're the only ones. Maybe not. > > What do you think the threshold should be? If one person objects, > should ComRel cease and desist? Two? Should we have a Gentoo-wide > vote? > > I don't have the highest opinion of ComRel and I'm a member, but maybe > you could let us do our jobs? I didn't say ComRel shouldn't do their job, nor offered any opinion on ComRel whatsoever. I said people shouldn't be called out on what looks like a legitimate question, and that quote was illustrating one of the reasons why. The threshold I'm talking about would be "is this question, however it's worded, relevant to the subject." Having said that, if this is you wearing a ComRel hat telling me to mind my own business, so be it. -- Sam Jorna (wraeth) GnuPG ID: 0xD6180C26 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Changes made by acct-* ebuilds
> Modification of system users and groups are also covered by that user. fix: <...> by that rule. -- Best regards, mva signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Changes made by acct-* ebuilds
> There's a significant difference between changing group membership for > a system user versus a user account that is used interactively. > > I don't think the handbook advises people to mess with system accounts. >From my experience this is quite common for web-stuff and similar things, where you suddenly want to be daemon1 in the group of daemon2 so it can read it's files. How about something like an EXTRA_GROUPS env var that one can set via profile? That could be set per package, acct-user templates could change that at merge time, or if USE=exact-groups is set even complain if the new and old group setting does not match. Or the other way round: always fail if the group membership of the given user is not exactly what the ebuild states + EXTRA_GROUPS, and let the user pass in USE=force-group for that ebuild to fix things up. Eike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Changes made by acct-* ebuilds
> > And now you're changing the subject. You've just claimed that *your* > user's group ownership will be overwritten and when challenged you > present the case of *system* user's group ownership being overwritten. Actually, he showed the rewrite of **system** user (that was modified locally). And, as it already mentioned above, this behaviour violates Gentoo Philosophy of not pretending to be smarter than user and don't dictate them a way to go. So, if the problem is only in the existance of the bug, I can create it tomorrow morning. But it would be great to know that it wont be closed in a minute after with "WONTFIX, works as expected". Also, as already stated, changing the stuff that was modified by user is **prohibited**. P.S. I don't care about your relations with whissi, but let's back to the topic: [big red letters] We should **NEVER** ever rewrite any system configuration made by local system administrator (call it "user" or whatever). Dixi. [/big red letters] Modification of system users and groups are also covered by that user. So, we, actually don't need any changes to disable acct-* things at all and make users to manage all the things by themselves. We need a change that will prevent any changes over **already existing** user. I think we should make it in a manner like: 1) when we install acct-pkg for a first time - CONFIG_PROTECT changes, and let user to review. 2) when we **reinstall** same package - do **nothing**. Although, I'm not sure here: on the one hand, why should we bother users by merging changes they already did before, on the other hand, it can be useful way to reset to defaults in case if "all this stuff is screwed up". 3) when we upgrade acct-package (assuming there was changes) - only allow "positive" changes (group additions), but not negative (dropiing groups), and anyway CONFIG_PROTECT all the changes. Well, there is also "kludgy way": does not globally reimplement anything, but: 1) force CFGPROTECT 2) perform a "light" modification to only perform "positive" modifications (see above) on users/groups, but no "negatives". It will anyway fix the both issues Whissi and OP had. -- Best regards, mva signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Changes made by acct-* ebuilds
On Fri, Feb 14, 2020 at 12:42 PM Thomas Deutschmann wrote: > > > # usermod -aG thomas postfix > > # id postfix > > uid=207(postfix) gid=207(postfix) > groups=207(postfix),12(mail),1004(thomas) > > # emerge -a1 acct-user/postfix > > [...] > > > > >>> Installing (1 of 1) acct-user/postfix-0::gentoo > > * checking 0 files for package collisions > > >>> Merging acct-user/postfix-0 to / > > >>> Safely unmerging already-installed instance... > > No package files given... Grabbing a set. > > >>> Regenerating /etc/ld.so.cache... > > >>> Original instance of package unmerged safely. > > * Updating groups for user 'postfix' ... > > * - Groups: postfix,mail > > >>> acct-user/postfix-0 merged. > > >>> Auto-cleaning packages... > > > > [...] > > > > # id postfix > > uid=207(postfix) gid=207(postfix) groups=207(postfix),12(mail) > > There's a significant difference between changing group membership for a system user versus a user account that is used interactively. I don't think the handbook advises people to mess with system accounts.
Re: [gentoo-dev] Changes made by acct-* ebuilds
On Fri, 2020-02-14 at 18:42 +0100, Thomas Deutschmann wrote: > > # usermod -aG thomas postfix > > # id postfix > > uid=207(postfix) gid=207(postfix) > groups=207(postfix),12(mail),1004(thomas) > > And now you're changing the subject. You've just claimed that *your* user's group ownership will be overwritten and when challenged you present the case of *system* user's group ownership being overwritten. Also, I'd like to point out that adding postfix user to group thomas is a counter-intuitive example. Someone could mistakenly assume you're adding user thomas to group postfix. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Changes made by acct-* ebuilds
> # usermod -aG thomas postfix > # id postfix > uid=207(postfix) gid=207(postfix) groups=207(postfix),12(mail),1004(thomas) > # emerge -a1 acct-user/postfix > [...] > > >>> Installing (1 of 1) acct-user/postfix-0::gentoo > * checking 0 files for package collisions > >>> Merging acct-user/postfix-0 to / > >>> Safely unmerging already-installed instance... > No package files given... Grabbing a set. > >>> Regenerating /etc/ld.so.cache... > >>> Original instance of package unmerged safely. > * Updating groups for user 'postfix' ... > * - Groups: postfix,mail > >>> acct-user/postfix-0 merged. > >>> Auto-cleaning packages... > > [...] > > # id postfix > uid=207(postfix) gid=207(postfix) groups=207(postfix),12(mail) > ...and if you read that council meeting log and even the mail discussion before you will read that I always shared concerns about touching existing user. I was only fine because I was told "We are aware, what you described won't happen" and I didn't make a secret that I didn't had the time to fully review and test myself at this time. Now I had the time to 'play' with this and it looks like all my previous concerns are true. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changes made by acct-* ebuilds
On Fri, 2020-02-14 at 18:09 +0100, Thomas Deutschmann wrote: > On 2020-02-14 16:38, Mike Gilbert wrote: > > Could you just explain please? I’m not inclined to read through the > > handbook and rebuild a system to guess what this horrible breakage might > > be. > > My point is, that even the handbook tells user to modify groups. I.e. > you should add your user to group X for being able to do Y... > > That's OK. That's normal. > > But if everything in Gentoo has migrated to acct-* stuff, these changes > will get reverted once the user will re-emerge world including acct-* > package or such a package will get updated for some reason. Why would that happen? We don't have acct-user/youruser. > This is unexpected. Also, I hope nobody expects that every user using > sudo for example needs to maintain an own acct-*/sudo fork in his/her > overlay in future just because in Gentoo, you cannot use normal Linux > tools like usermod anymore because your changes might get resetted > during some upgrade. Nope, this isn't true. You're getting things the other way around. > That's what currently might happen with the current implementation which > tries to keep user/group state like described in package. Something you > will only see in Gentoo and no other distribution. Have you really verified your claims? Because I really start feeling like you've voted for the GLEP without reading it, and then started recruiting people to change it based on guesses, still without reading it or understanding the implementation. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Changes made by acct-* ebuilds
On 2020-02-14 16:38, Mike Gilbert wrote: > Could you just explain please? I’m not inclined to read through the > handbook and rebuild a system to guess what this horrible breakage might > be. My point is, that even the handbook tells user to modify groups. I.e. you should add your user to group X for being able to do Y... That's OK. That's normal. But if everything in Gentoo has migrated to acct-* stuff, these changes will get reverted once the user will re-emerge world including acct-* package or such a package will get updated for some reason. This is unexpected. Also, I hope nobody expects that every user using sudo for example needs to maintain an own acct-*/sudo fork in his/her overlay in future just because in Gentoo, you cannot use normal Linux tools like usermod anymore because your changes might get resetted during some upgrade. That's what currently might happen with the current implementation which tries to keep user/group state like described in package. Something you will only see in Gentoo and no other distribution. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Fri, Feb 14, 2020 at 12:31 AM Sam Jorna (wraeth) wrote: > In this instance, at least two people (myself included) have drawn an > impression that led them to voice their concern in some way (I'm unsure if > mpagano was voicing concern or just agreeing with the general concept). Maybe > we're the only ones. Maybe not. What do you think the threshold should be? If one person objects, should ComRel cease and desist? Two? Should we have a Gentoo-wide vote? I don't have the highest opinion of ComRel and I'm a member, but maybe you could let us do our jobs?
Re: [gentoo-dev] Changes made by acct-* ebuilds
On Fri, Feb 14, 2020 at 9:12 AM Thomas Deutschmann wrote: > On 2020-02-13 17:17, Mike Gilbert wrote: > > I don't agree that this should be happen by default. I suspect the > > majority of users do not wish to manage system users/groups > > themselves. > > Follow handbook to get a working system and rebuild entire world. You > will get surprised. Could you just explain please? I’m not inclined to read through the handbook and rebuild a system to guess what this horrible breakage might be. >
[gentoo-dev] [PATCH] font.eclass: Don't assign FONT_S in global scope, allow an array.
Accessing ${S} in global scope is not allowed by PMS, therefore remove
the global variable assignment of FONT_S which uses it. Add a fallback
to ${S} in font_src_install() instead.
Allow FONT_S to be an array, if there are multiple directories.
Support for whitespace-separated lists will be kept for some time,
and a QA warning will be shown.
Die if pushd or popd fails.
Closes: https://bugs.gentoo.org/613108
Closes: https://bugs.gentoo.org/709578
Signed-off-by: Ulrich Müller
---
This will be committed in 60 days from now. The backwards compatibility
code for whitespace-separated FONT_S will be removed in one year.
* ATTENTION OVERLAY USERS *
If your ebuilds currently output error messages like:
/var/tmp/portage/media-fonts/foo/temp/environment: line 1036: pushd:
/var/tmp/portage/media-fonts/foo/work/foo: No such file or directory
/var/tmp/portage/media-fonts/foo/temp/environment: line 1043: popd: directory
stack empty
then in future these will be caught by the added "|| die" statements
after pushd and popd. So make sure to fix such breakage before the
updated eclass will be committed.
eclass/font.eclass | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/eclass/font.eclass b/eclass/font.eclass
index 1287f2273454..8418edf24ebb 100644
--- a/eclass/font.eclass
+++ b/eclass/font.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2019 Gentoo Authors
+# Copyright 1999-2020 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: font.eclass
@@ -25,10 +25,10 @@ EXPORT_FUNCTIONS pkg_setup src_install pkg_postinst
pkg_postrm
FONT_SUFFIX=${FONT_SUFFIX:-}
# @ECLASS-VARIABLE: FONT_S
-# @REQUIRED
+# @DEFAULT_UNSET
# @DESCRIPTION:
-# Space delimited list of directories containing the fonts.
-FONT_S=${FONT_S:-${S}}
+# Directory containing the fonts. If unset, ${S} is used instead.
+# Can also be an array of several directories.
# @ECLASS-VARIABLE: FONT_PN
# @DESCRIPTION:
@@ -159,27 +159,38 @@ font_pkg_setup() {
font_src_install() {
local dir suffix commondoc
- set -- ${FONT_S:-${S}}
- if [[ $# -gt 1 ]]; then
- # if we have multiple FONT_S elements then we want to recreate
the dir
- # structure
+ if [[ $(declare -p FONT_S) == "declare -a "* ]]; then
+ # recreate the directory structure if FONT_S is an array
+ for dir in "${FONT_S[@]}"; do
+ pushd "${dir}" > /dev/null || die "pushd ${dir} failed"
+ insinto "${FONTDIR}${dir#${S}}"
+ for suffix in ${FONT_SUFFIX}; do
+ doins *.${suffix}
+ done
+ font_xfont_config "${dir}"
+ popd > /dev/null || die
+ done
+ elif [[ ${FONT_S/ } != "${FONT_S}" ]]; then
+ # backwards compatibility code, can be removed after 2021-02-14
+ eqawarn "Using a space-separated list for FONT_S is deprecated."
+ eqawarn "Use a bash array instead if there are multiple
directories."
for dir in ${FONT_S}; do
- pushd "${dir}" > /dev/null
+ pushd "${dir}" > /dev/null || die "pushd ${dir} failed"
insinto "${FONTDIR}/${dir//${S}/}"
for suffix in ${FONT_SUFFIX}; do
doins *.${suffix}
done
font_xfont_config "${dir}"
- popd > /dev/null
+ popd > /dev/null || die
done
else
- pushd "${FONT_S}" > /dev/null
+ pushd "${FONT_S:-${S}}" > /dev/null || die "pushd ${dir} failed"
insinto "${FONTDIR}"
for suffix in ${FONT_SUFFIX}; do
doins *.${suffix}
done
font_xfont_config
- popd > /dev/null
+ popd > /dev/null || die
fi
font_fontconfig
--
2.25.0
signature.asc
Description: PGP signature
Re: [gentoo-dev] Changes made by acct-* ebuilds
On Fri, 2020-02-14 at 15:12 +0100, Thomas Deutschmann wrote: > On 2020-02-13 17:17, Mike Gilbert wrote: > > I don't agree that this should be happen by default. I suspect the > > majority of users do not wish to manage system users/groups > > themselves. > > Follow handbook to get a working system and rebuild entire world. You > will get surprised. > > This is really a bad default and it's breaking with existing principles > you can find in most distributions: Don't touch stuff which were changed > by the user. > So we're apparently dealing with a major breakage where nobody bothered to report a bug, and it's so urgent that instead of opening a bug you choose to try to push things your way behind the scenes causing more users to be hurt by this apparent non-reported bug just so you can have a better chance of pushing things your way and ignoring the other side of the resulting breakage. Makes sense. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Changes made by acct-* ebuilds
On 2020-02-13 17:17, Mike Gilbert wrote: > I don't agree that this should be happen by default. I suspect the > majority of users do not wish to manage system users/groups > themselves. Follow handbook to get a working system and rebuild entire world. You will get surprised. This is really a bad default and it's breaking with existing principles you can find in most distributions: Don't touch stuff which were changed by the user. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Friday, 14 February 2020 2:21:32 PM AEDT Matt Turner wrote: > On Thu, Feb 13, 2020 at 4:12 AM Mike Pagano wrote: > > On Thu, Feb 13, 2020 at 06:46:43PM +1100, Sam Jorna (wraeth) wrote: > > > On Thursday, 13 February 2020 5:40:46 AM AEDT Matt Turner wrote: > > > > On Wed, Feb 12, 2020 at 9:59 AM William Hubbs wrote: > > > > > On Wed, Feb 12, 2020 at 06:54:19PM +1100, Sam Jorna (wraeth) wrote: > > > > > > On Monday, 10 February 2020 7:55:01 AM AEDT Michał Górny wrote: > > > > > > > On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote: > > > > > > > > Hrm, pardon my ignorance, but do 'we' really need to review > > > > > > > > 232 > > > > > > > > lines of > > > > > > > > Manifest?! > > > > > > > > > > > > > > Pardon mine but do 'we' really need to read your useless > > > > > > > comments > > > > > > > everywhere, all the time and just get irritated for no benefit > > > > > > > to > > > > > > > Gentoo? > > > > > > > > > > > > Perhaps I'm the one being ignorant here, but why are we lambasting > > > > > > someone for seeking clarification about an unusual inclusion on a > > > > > > review thread?> > > > > > > > > > > I wasn't going to say anything, but I can't let this go by without > > > > > commenting. > > > > > > > > > > Sam is correct. Maybe the tone is a bit off, (and that is > > > > > debatable), > > > > > but this definitely can be seen as a legit question, regardless of > > > > > other > > > > > things Michael has posted. > > > > > > > > Unfortunately it's not about a single issue or email. It's a > > > > consistent pattern that multiple people have asked him to rein in over > > > > a long period. :( > > > > > > Without going into specifics, veremit and I have certainly had our > > > 'differences of opinion' in the past; but I don't believe this is one > > > of those occasions. > > > > > > Calling out bad actors (not saying veremit is one, I just mean in the > > > general sense) is an unfortunate but important task, but call them out > > > on bad behaviour, not for what appears to be an impassioned but > > > otherwise unremarkable query. > > > > I agree with this 100 percent. Not judging solely on the content of the > > specific email in the thread does not allow people to grow and improve. > > Are we all to be judged on our past behavior forever with no chance to > > overcome past transgressions ? > > That's not what's going on. Maybe not; but that's what appears is going on. mpagano is absolutely correct that people need an opportunity to engage positively if they're expected to change their behaviour in a positive way. At the same time, however, chastising someone without an apparent transgression both reinforces negative behaviour (such as the subsequent mails on that sub- thread) *and* gives anyone not intimately familiar with that particular case the impression that people are ridiculed because they asked a relevant question (since there's no other context). In this instance, at least two people (myself included) have drawn an impression that led them to voice their concern in some way (I'm unsure if mpagano was voicing concern or just agreeing with the general concept). Maybe we're the only ones. Maybe not. I understand that you or others may have had a history of issues dealing with someone, perhaps to the point where even seeing their name puts a damper on your day. I'm sure there are people who feel the same about me. But let bad actors dig their own hole to fall in, even if you're certain beyond the shadow of a doubt that they're sitting in a darkened lair, twirling their moustache and saying things like "my evil plan is coming to fruition!"; because lashing out at an unrelated list post just looks like you're being an asshole. -- Sam Jorna (wraeth) GnuPG ID: 0xD6180C26 signature.asc Description: This is a digitally signed message part.
