[gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Sam James]

This adds two tmpfiles related QA checks:
1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
is a deprecated location;

2) Check whether packages inherit tmpfiles.eclass if they're
installing files to /usr/lib/tmpfiles.d.

(This helps to catch packages not calling tmpfiles_process
in pkg_postinst).

Signed-off-by: Sam James <sam@gentoo.org>
---
 metadata/install-qa-check.d/60tmpfiles-paths | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 metadata/install-qa-check.d/60tmpfiles-paths

diff --git a/metadata/install-qa-check.d/60tmpfiles-paths b/metadata/install-qa-check.d/60tmpfiles-paths
new file mode 100644
index 0000000000000..2c56c031bd1e3
--- /dev/null
+++ b/metadata/install-qa-check.d/60tmpfiles-paths
@@ -0,0 +1,37 @@
+# Copyright 2021 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# QA check: ensure that packages installing tmpfiles configuration inherit the eclass
+# Maintainer: Sam James <sam@gentoo.org>
+
+# Implements two checks:
+# 1) Installation to /etc/tmpfiles.d (which is a deprecated location);
+# 2) Installation of any tmpfiles to /usr/lib/tmpfiles.d without inheriting the eclass
+#    (needed for tmpfiles_process in pkg_postinst)
+tmpfiles_check() {
+	# Check 1
+	# Scan image for files in /etc/tmpfiles.d which is a deprecated location
+	if [[ -d "${ED}"/etc/tmpfiles.d/ ]] ; then
+		eqawarn "QA Notice: files installed to the deprecated /etc/tmpfiles.d location"
+		eqawarn "tmpfiles configuration files must be installed to /usr/lib/tmpfiles.d!"
+	fi
+
+	# Check 2
+	# We're now going to check for whether we install files to /usr/lib/tmpfiles.d without
+	# inheriting the eclass (weak catch for ebuilds not calling tmpfiles_process in pkg_postinst)
+
+	# No need to carry on if we're inheriting the eclass
+	if has tmpfiles ${INHERITED} ; then
+		return
+	fi
+
+	if [[ -d "${ED}"/usr/lib/tmpfiles.d/ ]] ; then
+		eqawarn "QA Notice: package is installing tmpfiles without inheriting tmpfiles.eclass!"
+		eqawarn "Packages must inherit tmpfiles.eclass then call tmpfiles_process in pkg_postinst."
+	fi
+}
+
+tmpfiles_check
+: # guarantee successful exit
+
+# vim:ft=sh
-- 
2.32.0

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Michał Górny]

On Sun, 2021-08-01 at 00:56 +0100, Sam James wrote:
> This adds two tmpfiles related QA checks:
> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
> is a deprecated location;
> 
> 2) Check whether packages inherit tmpfiles.eclass if they're
> installing files to /usr/lib/tmpfiles.d.
> 
> (This helps to catch packages not calling tmpfiles_process
> in pkg_postinst).
> 
> Signed-off-by: Sam James <sam@gentoo.org>
> ---
>  metadata/install-qa-check.d/60tmpfiles-paths | 37 ++++++++++++++++++++
>  1 file changed, 37 insertions(+)
>  create mode 100644 metadata/install-qa-check.d/60tmpfiles-paths
> 
> diff --git a/metadata/install-qa-check.d/60tmpfiles-paths b/metadata/install-qa-check.d/60tmpfiles-paths
> new file mode 100644
> index 0000000000000..2c56c031bd1e3
> --- /dev/null
> +++ b/metadata/install-qa-check.d/60tmpfiles-paths
> @@ -0,0 +1,37 @@
> +# Copyright 2021 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# QA check: ensure that packages installing tmpfiles configuration inherit the eclass
> +# Maintainer: Sam James <sam@gentoo.org>
> +
> +# Implements two checks:
> +# 1) Installation to /etc/tmpfiles.d (which is a deprecated location);
> +# 2) Installation of any tmpfiles to /usr/lib/tmpfiles.d without inheriting the eclass
> +#    (needed for tmpfiles_process in pkg_postinst)
> +tmpfiles_check() {
> +	# Check 1
> +	# Scan image for files in /etc/tmpfiles.d which is a deprecated location
> +	if [[ -d "${ED}"/etc/tmpfiles.d/ ]] ; then

Nit: normally quoting is not necessary inside [[ ... ]].

> +		eqawarn "QA Notice: files installed to the deprecated /etc/tmpfiles.d location"
> +		eqawarn "tmpfiles configuration files must be installed to /usr/lib/tmpfiles.d!"
> +	fi
> +
> +	# Check 2
> +	# We're now going to check for whether we install files to /usr/lib/tmpfiles.d without
> +	# inheriting the eclass (weak catch for ebuilds not calling tmpfiles_process in pkg_postinst)
> +
> +	# No need to carry on if we're inheriting the eclass
> +	if has tmpfiles ${INHERITED} ; then
> +		return
> +	fi
> +
> +	if [[ -d "${ED}"/usr/lib/tmpfiles.d/ ]] ; then
> +		eqawarn "QA Notice: package is installing tmpfiles without inheriting tmpfiles.eclass!"
> +		eqawarn "Packages must inherit tmpfiles.eclass then call tmpfiles_process in pkg_postinst."
> +	fi
> +}
> +
> +tmpfiles_check
> +: # guarantee successful exit
> +
> +# vim:ft=sh

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Mike Gilbert]

On Sat, Jul 31, 2021 at 7:56 PM Sam James <sam@gentoo.org> wrote:
>
> This adds two tmpfiles related QA checks:
> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
> is a deprecated location;

sys-apps/systemd calls keepdir /etc/tmpfiles.d so that users don't get
confused by a missing directory.

How would you suggest I avoid this QA warning?

> 2) Check whether packages inherit tmpfiles.eclass if they're
> installing files to /usr/lib/tmpfiles.d.
>
> (This helps to catch packages not calling tmpfiles_process
> in pkg_postinst).

sys-apps/systemd installs many files in /usr/lib/tmpfiles.d, but
calling tmpfiles_process would probably not make much sense.

How would you suggest I avoid this QA warning?

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]



> On 1 Aug 2021, at 17:42, Mike Gilbert <floppym@gentoo.org> wrote:
> 
> On Sat, Jul 31, 2021 at 7:56 PM Sam James <sam@gentoo.org> wrote:
>> 
>> This adds two tmpfiles related QA checks:
>> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
>> is a deprecated location;
> 
> sys-apps/systemd calls keepdir /etc/tmpfiles.d so that users don't get
> confused by a missing directory.
> 
> How would you suggest I avoid this QA warning?

We can change the check to be for installing files within the directory?

> 
>> 2) Check whether packages inherit tmpfiles.eclass if they're
>> installing files to /usr/lib/tmpfiles.d.
>> 
>> (This helps to catch packages not calling tmpfiles_process
>> in pkg_postinst).
> 
> sys-apps/systemd installs many files in /usr/lib/tmpfiles.d, but
> calling tmpfiles_process would probably not make much sense.
> 
> How would you suggest I avoid this QA warning?
> 

We'll probably hardcode a list of folks who need to do this:
- sys-libs/pam
- sys-apps/systemd
(I'll check for any others, but I don't believe there are any now).

How about that?

best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Mike Gilbert]

On Sun, Aug 1, 2021 at 1:24 PM Sam James <sam@gentoo.org> wrote:
>
>
>
> > On 1 Aug 2021, at 17:42, Mike Gilbert <floppym@gentoo.org> wrote:
> >
> > On Sat, Jul 31, 2021 at 7:56 PM Sam James <sam@gentoo.org> wrote:
> >>
> >> This adds two tmpfiles related QA checks:
> >> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
> >> is a deprecated location;
> >
> > sys-apps/systemd calls keepdir /etc/tmpfiles.d so that users don't get
> > confused by a missing directory.
> >
> > How would you suggest I avoid this QA warning?
>
> We can change the check to be for installing files within the directory?

Works for me. Note that keepdir actually installs a dotfile,
(.keep-${CATEGORY}_${PN}-${SLOT}), so we would want to exclude that.
Also, systemd-tmpfiles looks for *.conf and ignores other files, so we
could probably ignore them too.

Maybe something like this:

files=( "${ED}"/etc/tmpfiles.d/*.conf )
if [[ ${#files[@]} -gt 0 ]]; then
...

> >
> >> 2) Check whether packages inherit tmpfiles.eclass if they're
> >> installing files to /usr/lib/tmpfiles.d.
> >>
> >> (This helps to catch packages not calling tmpfiles_process
> >> in pkg_postinst).
> >
> > sys-apps/systemd installs many files in /usr/lib/tmpfiles.d, but
> > calling tmpfiles_process would probably not make much sense.
> >
> > How would you suggest I avoid this QA warning?
> >
>
> We'll probably hardcode a list of folks who need to do this:
> - sys-libs/pam
> - sys-apps/systemd
> (I'll check for any others, but I don't believe there are any now).
>
> How about that?

I'm not crazy about hard-coding package names inside a QA check.
Personally, I would prefer a magic variable I could set to disable the
check from the ebuild side.

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Georgy Yakovlev]

[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]

On Saturday, July 31, 2021 4:56:34 PM PDT Sam James wrote:
> This adds two tmpfiles related QA checks:
> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
> is a deprecated location;
> 
> 2) Check whether packages inherit tmpfiles.eclass if they're
> installing files to /usr/lib/tmpfiles.d.
> 
> (This helps to catch packages not calling tmpfiles_process
> in pkg_postinst).
> 
> Signed-off-by: Sam James <sam@gentoo.org>
> ---
>  metadata/install-qa-check.d/60tmpfiles-paths | 37 ++++++++++++++++++++
>  1 file changed, 37 insertions(+)
>  create mode 100644 metadata/install-qa-check.d/60tmpfiles-paths
> 
> diff --git a/metadata/install-qa-check.d/60tmpfiles-paths
> b/metadata/install-qa-check.d/60tmpfiles-paths new file mode 100644
> index 0000000000000..2c56c031bd1e3
> --- /dev/null
> +++ b/metadata/install-qa-check.d/60tmpfiles-paths
> @@ -0,0 +1,37 @@
> +# Copyright 2021 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# QA check: ensure that packages installing tmpfiles configuration inherit
> the eclass +# Maintainer: Sam James <sam@gentoo.org>
> +
> +# Implements two checks:
> +# 1) Installation to /etc/tmpfiles.d (which is a deprecated location);
> +# 2) Installation of any tmpfiles to /usr/lib/tmpfiles.d without inheriting
> the eclass +#    (needed for tmpfiles_process in pkg_postinst)
> +tmpfiles_check() {
> +	# Check 1
> +	# Scan image for files in /etc/tmpfiles.d which is a deprecated 
location
> +	if [[ -d "${ED}"/etc/tmpfiles.d/ ]] ; then
> +		eqawarn "QA Notice: files installed to the deprecated /etc/
tmpfiles.d
> location" +		eqawarn "tmpfiles configuration files must be 
installed to
> /usr/lib/tmpfiles.d!" +	fi
> +
> +	# Check 2
> +	# We're now going to check for whether we install files to
> /usr/lib/tmpfiles.d without +	# inheriting the eclass (weak catch for
> ebuilds not calling tmpfiles_process in pkg_postinst) +
> +	# No need to carry on if we're inheriting the eclass
> +	if has tmpfiles ${INHERITED} ; then
> +		return

it can actually check if ebuild calls tmpfiles_process, not only inherit.
something like:

    local pkg_postinst_body="$(declare -fp pkg_postinst)"
    if [[ ! ${pkg_postinst_body} == *tmpfiles_process* ]]; then
        eqawarn "QA Notice: package is installing tmpfiles without calling
        eqawarn "tmpfiles_process in pkg_postinst phase"
    fi
    
ofc accounting for edge cases floppym mentioned.

> +	fi
> +
> +	if [[ -d "${ED}"/usr/lib/tmpfiles.d/ ]] ; then
> +		eqawarn "QA Notice: package is installing tmpfiles without 
inheriting
> tmpfiles.eclass!" +		eqawarn "Packages must inherit tmpfiles.eclass 
then
> call tmpfiles_process in pkg_postinst." +	fi
> +}
> +
> +tmpfiles_check
> +: # guarantee successful exit
> +
> +# vim:ft=sh


-- 
Best regards,
Georgy

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Michał Górny]

On Mon, 2021-08-02 at 01:28 -0700, Georgy Yakovlev wrote:
> it can actually check if ebuild calls tmpfiles_process, not only
> inherit.
> something like:
> 
>     local pkg_postinst_body="$(declare -fp pkg_postinst)"
>     if [[ ! ${pkg_postinst_body} == *tmpfiles_process* ]]; then
>         eqawarn "QA Notice: package is installing tmpfiles without
> calling
>         eqawarn "tmpfiles_process in pkg_postinst phase"
>     fi
>     
> ofc accounting for edge cases floppym mentioned.

This is going to cause false positives if tmpfiles_process is called via
another function.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Georgy Yakovlev]

On Monday, August 2, 2021 1:30:07 AM PDT Michał Górny wrote:
> On Mon, 2021-08-02 at 01:28 -0700, Georgy Yakovlev wrote:
> > it can actually check if ebuild calls tmpfiles_process, not only
> > inherit.
> > something like:
> > 
> >     local pkg_postinst_body="$(declare -fp pkg_postinst)"
> >     if [[ ! ${pkg_postinst_body} == *tmpfiles_process* ]]; then
> >         eqawarn "QA Notice: package is installing tmpfiles without
> > calling
> >         eqawarn "tmpfiles_process in pkg_postinst phase"
> >     fi
> >    
> > ofc accounting for edge cases floppym mentioned.
> 
> This is going to cause false positives if tmpfiles_process is called via
> another function.

ineed, but seems there are no such cases yet.
simple test (via ripgrep): prints all files calling tmpfiles_process at any 
point, and checks if any files from the list do not have a string ^pkg_postinst
it  may not catch all ofc, because it does not check where call happens or if 
it's actually defined, but I think it's good enough.

rg tmpfiles_process --files-with-matches | xargs rg ^pkg_postinst --files-
without-match

1 result, eclass/tmpfiles.eclass, which is fine.

I think adding body checker outweighs possible edge case yet to happen.
ebuilds not calling it already happened, we fixed some.
for example, logrotate was broken out of the box on systemd.

-- 
Best regards,
Georgy

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 455 bytes --]

On 2021-08-01 01:56, Sam James wrote:
> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
> is a deprecated location;

This location is _not_ deprecated.

This is the location for the local system administrator to override 
tmpfiles.d specifications installed by packages which should install 
below /usr.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]



> On 4 Aug 2021, at 03:39, Thomas Deutschmann <whissi@gentoo.org> wrote:
> 
> On 2021-08-01 01:56, Sam James wrote:
>> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
>> is a deprecated location;
> 
> This location is _not_ deprecated.
> 
> This is the location for the local system administrator to override tmpfiles.d specifications installed by packages which should install below /usr.
> 
> 

Sure, thanks for the clarification. It's deprecated in the sense of ebuilds installing to it though, right?

best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1122 bytes --]

On 2021-08-04 04:56, Sam James wrote:
> Sure, thanks for the clarification. It's deprecated in the sense of
> ebuilds installing to it though, right?

Well, it triggered me because saying it's deprecated implies two things 
for me:

1) It was OK for packages to do that in the past

2) Something has changed upstream

Regarding 1)
It was never OK for packages to install in that location. That will 
break the override mechanism systemd introduced. I.e. packages were and 
are still only allowed to install below /usr (/lib), to allow local 
system administrators to override installed unit/tmpfiles spec by 
placing a file with the same name in the corresponding directory in /etc.


Regarding 2)
Nothing has changed upstream regarding these locations.


I personally hope that this QA check will never fire in hope we never 
added an ebuild doing something like that but in the end, that's the 
idea of having such a check: To notice something like that, just in case ;-)


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Alec Warner]

On Tue, Aug 3, 2021 at 7:56 PM Sam James <sam@gentoo.org> wrote:
>
>
>
> > On 4 Aug 2021, at 03:39, Thomas Deutschmann <whissi@gentoo.org> wrote:
> >
> > On 2021-08-01 01:56, Sam James wrote:
> >> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
> >> is a deprecated location;
> >
> > This location is _not_ deprecated.
> >
> > This is the location for the local system administrator to override tmpfiles.d specifications installed by packages which should install below /usr.
> >
> >
>
> Sure, thanks for the clarification. It's deprecated in the sense of ebuilds installing to it though, right?

What if I use ebuilds to configure my local system settings? ;)

-A

>
> best,
> sam

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Matt Turner]

On Wed, Aug 4, 2021 at 5:35 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
>
> On 2021-08-04 04:56, Sam James wrote:
> > Sure, thanks for the clarification. It's deprecated in the sense of
> > ebuilds installing to it though, right?
>
> Well, it triggered me because saying it's deprecated implies two things
> for me:
>
> 1) It was OK for packages to do that in the past
>
> 2) Something has changed upstream
>
> Regarding 1)
> It was never OK for packages to install in that location. That will
> break the override mechanism systemd introduced. I.e. packages were and
> are still only allowed to install below /usr (/lib), to allow local
> system administrators to override installed unit/tmpfiles spec by
> placing a file with the same name in the corresponding directory in /etc.
>
>
> Regarding 2)
> Nothing has changed upstream regarding these locations.

Maybe next time, just explain that the first time around?

Your first email provides no actionable information and requires the
other party to expend effort (and wait for a reply) to understand what
you mean.

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[David Seifert]

On Wed, 2021-08-04 at 14:35 +0200, Thomas Deutschmann wrote:
> On 2021-08-04 04:56, Sam James wrote:
> > Sure, thanks for the clarification. It's deprecated in the sense of
> > ebuilds installing to it though, right?
> 
> Well, it triggered me because saying it's deprecated implies two
> things 
> for me:
> 
> 1) It was OK for packages to do that in the past
> 
> 2) Something has changed upstream
> 
> Regarding 1)
> It was never OK for packages to install in that location. That will 
> break the override mechanism systemd introduced. I.e. packages were
> and 
> are still only allowed to install below /usr (/lib), to allow local 
> system administrators to override installed unit/tmpfiles spec by 
> placing a file with the same name in the corresponding directory in
> /etc.
> 
> 
> Regarding 2)
> Nothing has changed upstream regarding these locations.
> 
> 
> I personally hope that this QA check will never fire in hope we never 
> added an ebuild doing something like that but in the end, that's the 
> idea of having such a check: To notice something like that, just in
> case ;-)

So you've created a big commotion... because you didn't get the initial
point? Honestly, this seems to be a recurring theme at this point.
Someone suggests some improved check/some change, and nowadays you can
bet 50 quid that Whissi will pop up and bikeshed it in some way.

It's become a real problem at this point. In fact, we have proxy
maintainers publicly refusing to work on packages somehow involving you
(I'll mention no names, but check the #-desktop backlog), because your
personality boils down to three attributes nowadays:

1. If I say the sky is blue, you'll say it's green. If I say it's green,
you'll say it's blue. I've had at least 5 people tell me they see the
exact same pattern in you (and no, mgorny is not part of that set,
before you throw that point at me). You're the textbook contrarian of
Gentoo ("Wutbürger") right now.
2. You'll tell people they are wrong, they aren't following protocols,
they made a mistake, but you will never follow through with actually
telling people what/why or how. By the time people ask you "why?",
you've already disappeared. Given how frequently this happens in
multiple channels, projects and at different time points, statistically,
this can't be explained by coincidence any more. This happens
practically on a daily basis, so you're not getting the benefit of the
doubt any more.
3. You can't let go. The security elections disaster right now is the
prime example (yes, it's public, just check the history of the Security
Project). This captures you so well: it's all about **community** and
stuff, until you lose, then you start invoking technicalities and
procedural shenanigans to justify some ludicrous kind of "co-lead" crap.
Frankly, it's embarrassing, and you're at the centre of it. Instead of
accepting defeat (remember, community and democracy!), you just fudge
the results.

At this point, you should really reflect on your current standing in
Gentoo. I'm not saying this to disparage you, but to appeal to some kind
of self-respect.

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 4063 bytes --]

On 2021-08-08 13:17, David Seifert wrote:
> So you've created a big commotion... because you didn't get the initial
> point? Honestly, this seems to be a recurring theme at this point.
> Someone suggests some improved check/some change, and nowadays you can
> bet 50 quid that Whissi will pop up and bikeshed it in some way.

No?

First of all, just because you disagree with something or believe a 
discussion is wrong and or not necessary and start to frame it as 
bikeshedding, it doesn't actually become bikeshedding. This is a very 
sad and transparent attempt to silence people through defamation.

The draft contains an error. It's saying that "/etc/tmpfiles.d" became 
deprecated which is not true. Because this would imply that it was 
previously acceptable for packages in Gentoo repository to install to 
that location which is not correct. If a packages in ::gentoo installed 
to /etc/tmpfiles.d before, this was already wrong.

And my point was and still is, that neither the commit message nor the 
eqawarn should use the wording "deprecated" because nothing has changed 
-- no location became deprecated.

And this will also address parts of antarus' previous mail: Because this 
QA check should be only about ::gentoo repository, this shouldn't affect 
any other repository. I.e. in your own overlay, you are free to do 
whatever you want and can't be forced to stick to Gentoo QA rules.


> It's become a real problem at this point. In fact, we have proxy
> maintainers publicly refusing to work on packages somehow involving you
> (I'll mention no names, but check the #-desktop backlog), because your
> personality boils down to three attributes nowadays:

I am not in that channel and never was. If you make such an allegation, 
include facts so that I can respond. If you look at my complete history 
at GitHub issues you will find that most people I worked with 
appreciated to work with me. Of course there are some bugs/PRs where I 
rejected a requested change but I am not sure what your point is. This 
is normal because not every PR is valid.


> 1. If I say the sky is blue, you'll say it's green. If I say it's green,
> you'll say it's blue. I've had at least 5 people tell me they see the
> exact same pattern in you (and no, mgorny is not part of that set,
> before you throw that point at me). You're the textbook contrarian of
> Gentoo ("Wutbürger") right now.
> 2. You'll tell people they are wrong, they aren't following protocols,
> they made a mistake, but you will never follow through with actually
> telling people what/why or how. By the time people ask you "why?",
> you've already disappeared. Given how frequently this happens in
> multiple channels, projects and at different time points, statistically,
> this can't be explained by coincidence any more. This happens
> practically on a daily basis, so you're not getting the benefit of the
> doubt any more.
> 3. You can't let go. The security elections disaster right now is the
> prime example (yes, it's public, just check the history of the Security
> Project). This captures you so well: it's all about **community** and
> stuff, until you lose, then you start invoking technicalities and
> procedural shenanigans to justify some ludicrous kind of "co-lead" crap.
> Frankly, it's embarrassing, and you're at the centre of it. Instead of
> accepting defeat (remember, community and democracy!), you just fudge
> the results.

Interesting. You don't even now my view on this but you already have an 
opinion and are saying that I am the culprit. I think this is called 
"prejudiced". I am pretty sure that as a ComRel member you will abstain 
from this case as you seem to be superior. I mean you are publicly 
attacking me for 10+ months, rejected any attempt from my side when I 
tried to speak with you to get things sorted and now you showed how 
biased your are...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[David Seifert]

On Mon, 2021-08-09 at 19:50 +0200, Thomas Deutschmann wrote:
> On 2021-08-08 13:17, David Seifert wrote:
> > So you've created a big commotion... because you didn't get the
> > initial
> > point? Honestly, this seems to be a recurring theme at this point.
> > Someone suggests some improved check/some change, and nowadays you
> > can
> > bet 50 quid that Whissi will pop up and bikeshed it in some way.
> 
> No?
> 
> First of all, just because you disagree with something or believe a 
> discussion is wrong and or not necessary and start to frame it as 
> bikeshedding, it doesn't actually become bikeshedding. This is a very 
> sad and transparent attempt to silence people through defamation.
> 
> The draft contains an error. It's saying that "/etc/tmpfiles.d" became
> deprecated which is not true. Because this would imply that it was 
> previously acceptable for packages in Gentoo repository to install to 
> that location which is not correct. If a packages in ::gentoo
> installed 
> to /etc/tmpfiles.d before, this was already wrong.
> 
> And my point was and still is, that neither the commit message nor the
> eqawarn should use the wording "deprecated" because nothing has
> changed 
> -- no location became deprecated.
> 
> And this will also address parts of antarus' previous mail: Because
> this 
> QA check should be only about ::gentoo repository, this shouldn't
> affect 
> any other repository. I.e. in your own overlay, you are free to do 
> whatever you want and can't be forced to stick to Gentoo QA rules.
> 
> 
> > It's become a real problem at this point. In fact, we have proxy
> > maintainers publicly refusing to work on packages somehow involving
> > you
> > (I'll mention no names, but check the #-desktop backlog), because
> > your
> > personality boils down to three attributes nowadays:
> 
> I am not in that channel and never was. If you make such an
> allegation, 
> include facts so that I can respond. If you look at my complete
> history 
> at GitHub issues you will find that most people I worked with 
> appreciated to work with me. Of course there are some bugs/PRs where I
> rejected a requested change but I am not sure what your point is. This
> is normal because not every PR is valid.

#gentoo-desktop:

[00:00:00] - {Day changed to Friday, 6 August 2021}
[...]
[13:32:33] <pinkflames[m]> soap: we went over this last week, 1. I'm not
making any more PRs where I do not receive the recognition I deserve and
2. working with Whissi is probably impossible ;(
[...]
[13:34:50] <pinkflames[m]> I'm not sure how well it got through since he
didn't seem to respond to my concerns but I could also tell that he
really has an authoritative decision making style

Timestamps so you can verify it with a third-party. This is a public
statement, I will not share statements by people who have confided in
me.

> > 1. If I say the sky is blue, you'll say it's green. If I say it's
> > green,
> > you'll say it's blue. I've had at least 5 people tell me they see
> > the
> > exact same pattern in you (and no, mgorny is not part of that set,
> > before you throw that point at me). You're the textbook contrarian
> > of
> > Gentoo ("Wutbürger") right now.
> > 2. You'll tell people they are wrong, they aren't following
> > protocols,
> > they made a mistake, but you will never follow through with actually
> > telling people what/why or how. By the time people ask you "why?",
> > you've already disappeared. Given how frequently this happens in
> > multiple channels, projects and at different time points,
> > statistically,
> > this can't be explained by coincidence any more. This happens
> > practically on a daily basis, so you're not getting the benefit of
> > the
> > doubt any more.
> > 3. You can't let go. The security elections disaster right now is
> > the
> > prime example (yes, it's public, just check the history of the
> > Security
> > Project). This captures you so well: it's all about **community**
> > and
> > stuff, until you lose, then you start invoking technicalities and
> > procedural shenanigans to justify some ludicrous kind of "co-lead"
> > crap.
> > Frankly, it's embarrassing, and you're at the centre of it. Instead
> > of
> > accepting defeat (remember, community and democracy!), you just
> > fudge
> > the results.
> 
> Interesting. You don't even now my view on this but you already have
> an 
> opinion and are saying that I am the culprit. I think this is called 
> "prejudiced".

To this day, we're still waiting for your view/statement/rebuttal of the
points, but have yet to receive anything.

> I am pretty sure that as a ComRel member you will abstain
> from this case as you seem to be superior. I mean you are publicly 
> attacking me for 10+ months, rejected any attempt from my side when I 
> tried to speak with you to get things sorted and now you showed how 
> biased your are...

The last message I received from you was on 10 Jul. I have sent 3
follow-up messages before Monday, 12 Jul (when the Bernd low hit
Germany). Since then, nothing. And before you invoke the Bernd argument:
I'm also a first responder, and while the high Rhine wasn't nearly as
badly affected as the middle Rhine/Eifel area in terms of floodings, I
understand that you might not have had the time to respond (even though
you pushed 19 commits to ::gentoo on 13 Jul). That said, "let me check
whether soap wrote something in PM" seems to have never occurred since
12 Jul at any point, which raises doubts as to whether this is such a
critical issue after all...

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

>>>>> On Fri, 13 Aug 2021, David Seifert wrote:

> On Mon, 2021-08-09 at 19:50 +0200, Thomas Deutschmann wrote:
>> Interesting. You don't even now my view on this but you already have
>> an opinion and are saying that I am the culprit. I think this is
>> called "prejudiced".

> To this day, we're still waiting for your view/statement/rebuttal of the
> points, but have yet to receive anything.

>> I am pretty sure that as a ComRel member you will abstain
>> from this case as you seem to be superior. I mean you are publicly 
>> attacking me for 10+ months, rejected any attempt from my side when I 
>> tried to speak with you to get things sorted and now you showed how 
>> biased your are...

> The last message I received from you was on 10 Jul. I have sent 3
> follow-up messages before Monday, 12 Jul (when the Bernd low hit
> Germany). Since then, nothing. And before you invoke the Bernd argument:
> I'm also a first responder, and while the high Rhine wasn't nearly as
> badly affected as the middle Rhine/Eifel area in terms of floodings, I
> understand that you might not have had the time to respond (even though
> you pushed 19 commits to ::gentoo on 13 Jul). That said, "let me check
> whether soap wrote something in PM" seems to have never occurred since
> 12 Jul at any point, which raises doubts as to whether this is such a
> critical issue after all...

Can you please take this discussion private? gentoo-dev is a technical
mailing list, and while [1] still qualifies as on-topic (IMHO), the
three messages following it in this sub-thread are off-topic here.

Ulrich

[1] https://archives.gentoo.org/gentoo-dev/message/565efeab6f253c402212fd8d8aa58945

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]