Hello,
Unlike most other XDG base directories[1], we do not do anything with
XDG_DATA_DIRS - not in xdg_environment_reset, nor in ENV_UNSET.
This is now causing some issues.
Historically there was an issue[2] where a package added XDG_DATA_DIRS
via env.d, which meant that if the base package (x1
Am Donnerstag, 12. August 2021, 19:39:08 CEST schrieb Michael Orlitzky:
> On Thu, 2021-08-12 at 17:22 +0200, Rolf Eike Beer wrote:
> > The default owner is root:root anyway.
>
> This is only true of you don't call insopts earlier with some other
> value. I see "insopts -o root -g qmail -m 700" in
Adding an extra keep file in the intermediate /var/qmail is never necessary,
and the binary directory is filled by the installation anyway.
Signed-off-by: Rolf Eike Beer
---
eclass/qmail.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/qmail.eclass b/eclass/q
> On Fri, 13 Aug 2021, Rolf Eike Beer wrote:
> Am Donnerstag, 12. August 2021, 19:39:08 CEST schrieb Michael Orlitzky:
>> On Thu, 2021-08-12 at 17:22 +0200, Rolf Eike Beer wrote:
>> > The default owner is root:root anyway.
>>
>> This is only true of you don't call insopts earlier with some ot
Hi Michał,
On Thu, 12 Aug 2021 14:53:33 +0200 Michał Górny wrote:
>Hello, everyone.
>
>TL;DR: I'd like to propose that stabilizations are done via blockers of
>security bugs instead of security bugs themselves, i.e. as any other
>stabilizations.
>
>
>Right now we're often performing security-rela
Am Freitag, 13. August 2021, 11:06:09 CEST schrieb Ulrich Mueller:
> > On Fri, 13 Aug 2021, Rolf Eike Beer wrote:
> > Am Donnerstag, 12. August 2021, 19:39:08 CEST schrieb Michael Orlitzky:
> >> On Thu, 2021-08-12 at 17:22 +0200, Rolf Eike Beer wrote:
> >> > The default owner is root:root anywa
This has been in all ebuilds since the move of the portage tree to git, so
everyone should have already moved the files.
Signed-off-by: Rolf Eike Beer
---
eclass/qmail.eclass| 22 --
mail-mta/netqmail/netqmail-1.06-r14.ebuild | 4
mail-mta/notqma
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/so
> 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 s
Hi,
>> It would be nice to be able to resolve the security@-assigned but
>> before non-security-supported architectures are handled.
>>
>> To do that, I think we'd want to change what's required for the "clean
>> up" step. Since today the "clean up" step is dropping the vulnerable
>> package versi
On Thu, Aug 12, 2021 at 01:17:32PM -0700, Matt Turner wrote:
> On Thu, Aug 12, 2021 at 5:53 AM Michał Górny wrote:
> >
> To do that, I think we'd want to change what's required for the "clean
> up" step. Since today the "clean up" step is dropping the vulnerable
> package versions from the tree
# David Seifert (2021-08-13)
# Dead upstream, new "forked" upstream that just added the last version
# on Github but doesn't maintain them. Unmaintained for the past 10
# years in ::gentoo, no other real distros package these anymore.
# HOMEPAGE leads to some scammy site.
# Bug #318143, #62, #
On Fri, 2021-08-13 at 12:50 -0400, Aaron Bauman wrote:
> On Thu, Aug 12, 2021 at 01:17:32PM -0700, Matt Turner wrote:
> > On Thu, Aug 12, 2021 at 5:53 AM Michał Górny wrote:
> > >
>
>
>
> > To do that, I think we'd want to change what's required for the "clean
> > up" step. Since today the "cl
13 matches
Mail list logo
