> On 13 Jul 2021, at 01:11, Sam James wrote:
>
>
>
>> On 13 Jul 2021, at 01:08, Marek Szuba wrote:
>>
>> On 2021-07-13 01:01, Marek Szuba wrote:
>>
>>> Title: PipeWire versions of PulseEffects are now media-sound/easyeffects
>>> Author: Marek Szuba
>>> Posted: 2021-07-16
>>> Revision: 1
> On 13 Jul 2021, at 01:08, Marek Szuba wrote:
>
> On 2021-07-13 01:01, Marek Szuba wrote:
>
>> Title: PipeWire versions of PulseEffects are now media-sound/easyeffects
>> Author: Marek Szuba
>> Posted: 2021-07-16
>> Revision: 1
>> News-Item-Format: 2.0
>> Display-If-Installed:
On 2021-07-13 01:01, Marek Szuba wrote:
Title: PipeWire versions of PulseEffects are now media-sound/easyeffects
Author: Marek Szuba
Posted: 2021-07-16
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: >=media-sound/pulseeffects-5.0.0
In response to the upstream decision to rename
Officially the new name has only been in effect since version 6.0.0 but
having discussed this with prometheanfire on IRC, it makes sense to
extend the new name to >=5.0.0 - that way people not interested in
switching from plain PulseAudio to PipeWire can continue to use v4
(which according to
Ben Kohler wrote:
> Nobody is "disabling choice" here,
Fair! Sorry about the hyperbole.
> a change in defaults doesn't remove your ability to choose something else.
True. My argument is more specificically that setting USE flags by
default in a "low-level" profile goes in the wrong direction.
On 7/12/21 12:25 PM, Michael Orlitzky wrote:
We've kept things the same level of difficulty for one group of people,
but made them much harder for another. In no situation can anyone who
wants everything enabled have a harder time than 'adds USE="bzip2 lzma
zstd" to make.conf', but everyone
On Mon, 2021-07-12 at 10:46 -0500, Ben Kohler wrote:
>
> Nobody is "disabling choice" here, a change in defaults doesn't remove
> your ability to choose something else.
I think what you're suggesting is that default-on is not any worse for
choice than default-off, since both can be changed?
On 11.7.2021 23.54, Michał Górny wrote:
> Hi, everyone.
>
>
>
> The point of contention was a proposed change to the EAPI depreciation
> workflow. The current workflow consists of roughly three steps:
>
> 1. The Council decides to deprecate an EAPI. It is added to eapis-
> deprecated in
On 7/12/21 10:30 AM, Peter Stuge wrote:
Matt Turner wrote:
If you can find a case where you wouldn't want to enable one of these
USE flags, please let me know and I'll reconsider my position.
My catalyst spec files all have use: -* foo bar x y z
specifically because the defaults are never
From: Florian Schmaus
Signed-off-by: Florian Schmaus
Signed-off-by: Michał Górny
---
eclass/distutils-r1.eclass | 6 ++
1 file changed, 6 insertions(+)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 3286842f0933..0236c576efc5 100644
---
The current errors about incorrect call context are cryptic at best.
Replace the inline checks with a single _python_check_EPYTHON function
and provide a verbose explanation how to fix the problem.
Signed-off-by: Michał Górny
---
eclass/distutils-r1.eclass| 2 +-
Matt Turner wrote:
> > > If you can find a case where you wouldn't want to enable one of these
> > > USE flags, please let me know and I'll reconsider my position.
> >
> > My catalyst spec files all have use: -* foo bar x y z
> > specifically because the defaults are never what I want for any
On Mon, Jul 12, 2021 at 04:59:06PM +0200, Michał Górny wrote:
> On Mon, 2021-07-12 at 09:33 -0400, Aaron Bauman wrote:
> > On Mon, Jul 12, 2021 at 11:38:18AM +0100, Marek Szuba wrote:
> > > On 2021-07-11 21:54, Michał Górny wrote:
> > >
> > > > My gut feeling is that having this distinction is
On Mon, 2021-07-12 at 09:33 -0400, Aaron Bauman wrote:
> On Mon, Jul 12, 2021 at 11:38:18AM +0100, Marek Szuba wrote:
> > On 2021-07-11 21:54, Michał Górny wrote:
> >
> > > My gut feeling is that having this distinction is useful. However, it
> > > has been pointed out that we've probably never
On Sun, 2021-07-11 at 15:53 +0200, Thomas Deutschmann wrote:
>
> Furthermore, tmpfiles.d settings are only supposed for creation,
> deletion and cleaning of volatile and temporary files. Any package which
> will install tmpfiles.d settings which will create files in persistent
> locations
On Mon, Jul 12, 2021 at 04:21:02PM +0200, Thomas Deutschmann wrote:
> Hi,
>
> it's not clear to me what will be the consequences of this change.
>
> I am expecting good faith and that nobody will add an ebuild with deprecated
> EAPI just for fun or because maintainer prefers retro stuff.
>
> So
Hi,
it's not clear to me what will be the consequences of this change.
I am expecting good faith and that nobody will add an ebuild with
deprecated EAPI just for fun or because maintainer prefers retro stuff.
So looking at the reasons to bump without touching EAPI:
a) Because of a changing
On Mon, Jul 12, 2021 at 11:38:18AM +0100, Marek Szuba wrote:
> On 2021-07-11 21:54, Michał Górny wrote:
>
> > My gut feeling is that having this distinction is useful. However, it
> > has been pointed out that we've probably never really had to use it
> > (i.e. use the "banned" argument to stop
# Marek Szuba (2021-07-12)
# No releases since March 2015, no upstream repo activity since November
# 2019. Unmaintained in Gentoo. Depends on effectively EOLed Lua 5.2,
# fails to build against any other version. Removal in 30 days
# (Bug #801883)
app-crypt/cardpeek
--
Marecki
On 2021-07-09 17:34, William Hubbs wrote:
Actually upstream does say when they will stop supporting each version
[1].
Um, where? Because I've looked at this page before, I've looked at it
again just now and I all can see there is that there will be no further
releases of Lua versions up to
On 2021-07-11 21:54, Michał Górny wrote:
My gut feeling is that having this distinction is useful. However, it
has been pointed out that we've probably never really had to use it
(i.e. use the "banned" argument to stop someone from using old EAPI)
and that the switch from "deprecated" to
On 2021-07-10 22:55, William Hubbs wrote:
Change the _R0 suffix on these variable names to _ECLASS.
Since my question in response to the previous round of this has yet to
be answered, I repeat: are there any non-cosmetic reasons for doing this?
--
Marecki
OpenPGP_signature
Description:
22 matches
Mail list logo