On Mon, Sep 07, 2020 at 07:44:33PM +0200, Michał Górny wrote:
> Hi,
>
> The following packages are up for grabs due to their maintainer being
> MIA.
>
> acct-group/monkeysphere
> acct-user/monkeysphere
> app-crypt/ekeyd
> app-crypt/monkeysphere
> app-crypt/nasty
> app-crypt/pinentry
> app-eselect
I have switched to nginx for the most of my services.
There are no critical bugs open, but some may require additional
investigation.
On 07.09.2020 20:44, Michał Górny wrote:
Hi,
The following packages are up for grabs due to their maintainer being
MIA.
acct-group/monkeysphere
acct-user/monkeysphere
app-crypt/ekeyd
app-crypt/monkeysphere
app-crypt/nasty
app-crypt/pinentry
app-eselect/eselect-pinentry
dev-libs/libgcrypt
dev-
Hi,
The following packages are up for grabs due to their maintainer being
MIA.
acct-group/monkeysphere
acct-user/monkeysphere
app-crypt/ekeyd
app-crypt/monkeysphere
app-crypt/nasty
app-crypt/pinentry
app-eselect/eselect-pinentry
dev-libs/libgcrypt
dev-libs/npth
net-misc/sks
www-apps/ampache
--
# Nothing in the tree uses this lib anymore. Removing as redundant.
# Removal in ~30 days. Bug #740868.
signature.asc
Description: OpenPGP digital signature
On 2020-09-06 17:46, David Seifert wrote:
> Unfortunately we won't get around a single-r1-style eclass too. What
> about all those programs embedding a specific lua version as plugin
> architecture?
This is still very much on my to-do list, I simply figured it would make
it easier for everyone re
> On Mon, 07 Sep 2020, Michael Orlitzky wrote:
> You're missing some context. In October of last year, a QA team member
> broke dependency resolution on a lot of systems by making the same sort
> of change that this patch proposes:
> https://archives.gentoo.org/gentoo-dev/message/64c42804eb4c
On 2020-09-07 08:47, Alessandro Barbieri wrote:
> Being consistent in decision is hard I see.
You're missing some context. In October of last year, a QA team member
broke dependency resolution on a lot of systems by making the same sort
of change that this patch proposes:
https://archives.gentoo.
> On Mon, 07 Sep 2020, Alessandro Barbieri wrote:
> Il giorno lun 7 set 2020 alle ore 14:10 Ulrich Mueller ha
> scritto:
>> We are talking about the second case here, because the dependency on the
>> virtual is being removed, while the dependency on its provider remains
>> in place (it only
Il giorno lun 7 set 2020 alle ore 14:10 Ulrich Mueller ha
scritto:
> The devmanual [1] says that a revbump should be done when a new runtime
> dependency is added to an ebuild, but it doesn't say that for removal of
> a dependency.
>
> We are talking about the second case here, because the depend
> On Mon, 07 Sep 2020, Michael Orlitzky wrote:
> On 2020-09-07 08:10, Ulrich Mueller wrote:
>> The devmanual [1] says that a revbump should be done when a new
>> runtime dependency is added to an ebuild, but it doesn't say that for
>> removal of a dependency.
> One dependency is removed, and
On 2020-09-07 08:10, Ulrich Mueller wrote:
>> This has caused dependency resolution problems in the past. The PMS
>> implies a new revision,
>
> PMS says nothing about new revisions or revision bumps:
>
That is indeed what the word "implies" implies.
> The devmanual [1] says that a revbump sho
> On Mon, 07 Sep 2020, Michael Orlitzky wrote:
> On 2020-09-07 02:14, Michał Górny wrote:
>> +
>> +Update all ebuilds not to reference the virtual. Since there is
>> +no urgent need to remove the virtual from user systems
>> +and the resulting rebuilds would be unnecessary, do no
On 2020-09-07 02:14, Michał Górny wrote:
> +
> +Update all ebuilds not to reference the virtual. Since there is
> +no urgent need to remove the virtual from user systems
> +and the resulting rebuilds would be unnecessary, do not bump ebuilds
> +when replacing the dependency.
> +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, 7 Sep 2020 21:39:54 +1200
Kent Fredric wrote:
> On Mon, 7 Sep 2020 08:14:52 +0200
> Michał Górny wrote:
>
> > However, please
> > +do not include it in the package.mask entry as users do
> > not need
> > +to be forced to proactiv
On Mon, 7 Sep 2020 08:14:52 +0200
Michał Górny wrote:
> However, please
> +do not include it in the package.mask entry as users do not need
> +to be forced to proactively unmerge it.
I can think of a utilitarian value of doing this anyway.
Namely, it gives a window during `emerge -uD @
On Mon, 2020-09-07 at 09:46 +0200, Ulrich Mueller wrote:
> > > > > > On Mon, 07 Sep 2020, Michał Górny wrote:
> > +
> > +If the virtual is being removed along with its second to last
> > +provider, include the virtual in the last-rites mail. However, please
>
> Maybe write "any of its pr
> On Mon, 07 Sep 2020, Michał Górny wrote:
> +
> +If the virtual is being removed along with its second to last
> +provider, include the virtual in the last-rites mail. However, please
Maybe write "any of its providers" instead of "its second to last
provider"? It is simpler and sti
> On Sun, 06 Sep 2020, David Seifert wrote:
> On Sun, 2020-09-06 at 21:49 +0200, Ulrich Mueller wrote:
>> Maybe just commit the new eclass, update ebuilds, then remove the
>> function from eutils?
> I'll get a lot of heat for breaking EAPI 2 ebuilds in some random
> abandoned overlay because
19 matches
Mail list logo
