> On Sun, 17 Sep 2023, Florian Schmaus wrote:
>
>
>
> sounds perfectly fine.
Don't use an attribute if you can put the information in the (otherwise
empty) element. Especially, when other elements like already do it
that way.
> It would require (minor) adjustments to the schema and
On 2023-09-17 20:28:49, Alexe Stefan wrote:
>
> There are 2 open pr's on the opentmpfiles github. One removes the
> security vulnerability, but is non-compliant with the spec, the other
> is (at least is a start of) a rewrite in c.
The PR is still vulnerable. These checks,
_chown() {
Signed-off-by: Volkmar W. Pogatzki
---
eclass/java-pkg-opt-2.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/java-pkg-opt-2.eclass b/eclass/java-pkg-opt-2.eclass
index 3a4b25ec2f0c..0caba1d40e07 100644
--- a/eclass/java-pkg-opt-2.eclass
+++
On 9/17/23 20:28, Florian Schmaus wrote:
sounds perfectly fine.
Ideally I'd not limit it to only doi but also arxiv, zenodo, inspirehep.
They can all be referenced by https://... . I agree a specific type is
kind of unnecessary. However, the same paper can be referenced by all of
Alexe Stefan writes:
> On 9/17/23, Arsen Arsenović wrote:
>> In the meanwhile, while the two downstream volunteers address that, an
>> ::eudev overlay can be established. As I went over in another email I
>> posted to this thread, it should not be particularly difficult to
>> implement or
On 17/09/2023 14.18, Alexander Neuwirth wrote:
Thanks. Instead of using the lang entry I can imagine these other
approaches:
2. Adding something specific to GLEP 68, like `type="doi"> https...`. However that seems like a bit too much work for
adding something that only a small subset of users
On 9/17/23, Arsen Arsenović wrote:
> In the meanwhile, while the two downstream volunteers address that, an
> ::eudev overlay can be established. As I went over in another email I
> posted to this thread, it should not be particularly difficult to
> implement or maintain (nowhere close to
On Sun, 17 Sep 2023 13:25:20 -0400
Michael Orlitzky wrote:
> On 2023-09-17 15:32:46, Marc Joliet wrote:
> > I just want to say how amazed I am that you (and Arsen, too) still
> > have the patience to try and explain the realities of the situation
> > like this, especially after the eudev thread.
On 9/17/23, orbea wrote:
> On Sun, 17 Sep 2023 12:58:00 +0200
> Arsen Arsenović wrote:
>
>> Alexe Stefan writes:
>>
>> > One is written in shell, the other is written in c.(no problems
>> > here)
>>
>> Not that implementation language matters.
>>
>> > One is not part of systemd, the other is.
On 2023-09-17 15:32:46, Marc Joliet wrote:
> I just want to say how amazed I am that you (and Arsen, too) still have the
> patience to try and explain the realities of the situation like this,
> especially after the eudev thread.
I'm a founding member of the systemd haters club so I'm
# Michał Górny (2023-09-17)
# Core API has not been maintained since 2017, and all the repositories
# have been archived in 2019. It remained in ::gentoo only
# as an optional test dependency, and all reverse dependencies have been
# updated not to depend on it.
# Removal on 2023-10-17. Bug
Am Sonntag, 17. September 2023, 15:32:46 CEST schrieb Marc Joliet:
> Am Sonntag, 17. September 2023, 13:53:45 CEST schrieb Michael Orlitzky:
> > On 2023-09-17 08:26:50, Alexe Stefan wrote:
> [...]
>
> I just want to say how amazed I am that you (and Arsen, too) still have the
> patience to try and
> On Sun, 17 Sep 2023, Alexander Neuwirth wrote:
> Thanks. Instead of using the lang entry I can imagine these other
> approaches:
> 1. doi/arxiv/... links could also easily be plugged in custom upstream
> remote ids, but that also feels a bit wrong since all other [upstream
> remote
>
On Sun, Sep 17, 2023 at 04:49:41PM +0200, Petr Vaněk wrote:
> tc-has-openmp function was deprecated in commit 9bc832c6d39b
> ("toolchain-funcs.eclass: deprecate tc-has-openmp") and later removed in
> commit eb970274d283 ("toolchain-funcs.eclass: remove tc-has-openmp").
> Due to this, the reference
tc-has-openmp function was deprecated in commit 9bc832c6d39b
("toolchain-funcs.eclass: deprecate tc-has-openmp") and later removed in
commit eb970274d283 ("toolchain-funcs.eclass: remove tc-has-openmp").
Due to this, the reference to it in the tc-check-openmp function has
become redundant and is
tc-has-openmp function was deprecated in commit 9bc832c6d39b
("toolchain-funcs.eclass: deprecate tc-has-openmp") and later removed in
commit eb970274d283 ("toolchain-funcs.eclass: remove tc-has-openmp").
Due to this, the reference to it in the tc-check-openmp function has
become redundant and is
Am Sonntag, 17. September 2023, 13:53:45 CEST schrieb Michael Orlitzky:
> On 2023-09-17 08:26:50, Alexe Stefan wrote:
[...]
I just want to say how amazed I am that you (and Arsen, too) still have the
patience to try and explain the realities of the situation like this,
especially after the eudev
On Sun, 17 Sep 2023 12:58:00 +0200
Arsen Arsenović wrote:
> Alexe Stefan writes:
>
> > One is written in shell, the other is written in c.(no problems
> > here)
>
> Not that implementation language matters.
>
> > One is not part of systemd, the other is.
>
> Both work fine without
Thanks. Instead of using the lang entry I can imagine these other
approaches:
1. doi/arxiv/... links could also easily be plugged in custom upstream
remote ids, but that also feels a bit wrong since all other [upstream
remote
On 2023-09-17 08:26:50, Alexe Stefan wrote:
> One is written in shell, the other is written in c.(no problems here)
> One is not part of systemd, the other is.
> How are they identical.
The big picture is that the tmpfiles.d specification is impossible to
implement securely on a POSIX system. The
Arsen Arsenović writes:
[snip]
>> How are they identical.
>
> The last rites message does not say that opentmpfiles and
> systemd-tmpfiles are identical. That'd do a disservice to the actually
> complete, unmaintained, and (currently) non-CVE-affected implementation
^^ C-h C-h...
Alexe Stefan writes:
> One is written in shell, the other is written in c.(no problems here)
Not that implementation language matters.
> One is not part of systemd, the other is.
Both work fine without systemd, but the systemd implementation also
happens not to be unmaintained and happens to
Alexe Stefan writes:
> Upstream, it's maintained.
See my other emails for an explanation of why looking at a commit graph
is not good enough to tell if something is maintained.
> Downstream, 2 people volunteered.
And proposed ugly 'fixes' (read: hacks).
> So it is maintained.
>
> The
On 9/17/23, Arsen Arsenović wrote:
>
> Alexe Stefan writes:
>
>> Yet another example of choice being restricted by gentoo.
>> However, there at least is a better reason for not keeping libressl in
>> ::Gentoo, that reason being qt.
>
> ... and the swathes of other packages that are not
On 9/17/23, David Seifert wrote:
> On Sun, 2023-09-17 at 08:26 +0300, Alexe Stefan wrote:
>> One is written in shell, the other is written in c.(no problems here)
>> One is not part of systemd, the other is.
>> How are they identical.
>>
>> I use this on my raspi server, works fine.
>>
>> Gentoo
On Sun, 2023-09-17 at 08:26 +0300, Alexe Stefan wrote:
> One is written in shell, the other is written in c.(no problems here)
> One is not part of systemd, the other is.
> How are they identical.
>
> I use this on my raspi server, works fine.
>
> Gentoo really became a systemd distro, further
26 matches
Mail list logo
