[gentoo-dev] RFC: UID/GID assignment for tss (59)

2019-11-02 Thread Salah Coronya

Hello,
I'd like to reserve UID/GID 59 for app-crypt/trousers, 
app-crypt/tpm2-tss, and app-crypt/tpm2-abrmd . All of them create the 
"tss" user. Fedora uses the same UID/GID for the "tss" user.


Pending PR: https://github.com/gentoo/gentoo/pull/13532

Thanks,
Salah Coronya



[gentoo-dev] RFC: UID/GID assignment for mongodb (481)

2019-11-02 Thread Tomas Mozes
Hello,
I'd like to reserve UID/GID 481 for dev-db/mongodb. UID/GID from fedora is
already taken, so allocating the next free.

Pending PR:
https://github.com/gentoo/gentoo/pull/13529

Thanks,
Tomas


Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

2019-11-02 Thread Michael 'veremitz' Everitt
On 02/11/19 08:54, Kent Fredric wrote:
> On Fri, 1 Nov 2019 19:59:35 +
> Michael 'veremitz' Everitt  wrote:
>
>> Thoughts from outside peanut gallery?
>>
>> Michael / veremitz.
> I have an alternative that might be more pleasant:
>
> 1. Change repoman so that when its clear that:
>- There is at least one ebuild being changed
>- There is only one ebuild being changed
>   Then the templated summary line is full ${P}
>
> 2. Otherwise, retain the current semantics of using a simpler
>${P} in other cases.
>
> 3. Make no *requirements* that ${P} be used instead of ${PN},
>and that way people who think they have a good reason to use ${PN}
>instead of ${P} can do just that (if for instance, they need to lop
>off context so they can have a longer commit message )
>
> This IMO improves things by default, given that the majority of changes
> get run through repoman, and a majority of changes have very terse
> requirements for extra data.
>
> It also means that by default, when people just make the commit message
> something silly like "bump", or "version bump", despite the fact they
> didn't put in much effort, the log defaults to being useful, and the
> commit messages relayed to #gentoo-commits improves in usefulness.
>
> Partly, because for me, one of my prime vectors where I become aware
> changes are occuring is in #gentoo commits, particularly because
> something in there highlights me.
>
> I don't want to *have* to:
> - Resync my git repo 
> - Dig into git wizardry 
>
> *just* to ascertain what version was involved, and to then ascertain if
> I need to investigate further.
>
> ( Because once I've already synced and started using git wizardry, I'm
> already starting to pay investigation taxes )
>
>
This sounds like a good compromise, and one I'm content to work on. Anyone
else able/willing to pitch in?



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] CI now distinguishes new problems

2019-11-02 Thread Michał Górny
Hello, everyone.

Today the CI system received another upgrade and was made aware
of exclusion lists.  This makes it possible for it to report new
problems without triggering for all existing violations.

In other words, from now on CI will start reporting violations
on new packages and new versions of packages even if they were present
in the previous versions.

FWICS everything works as expected, and CI already reported two new
violations that weren't present when I populated the exclusion list.
If you notice any problems, please ping me.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-admin/linux-bench/

2019-11-02 Thread Michał Górny
On Tue, 2019-10-29 at 10:10 +, Manuel Rüger wrote:
> commit: 0f5c4a120b506866a4405e7d6391839d919e13e5
> Author: Manuel Rüger  gentoo  org>
> AuthorDate: Tue Oct 29 10:08:25 2019 +
> Commit: Manuel Rüger  gentoo  org>
> CommitDate: Tue Oct 29 10:09:05 2019 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0f5c4a12
> 
> app-admin/linux-bench: Initial version

[...]

> +LICENSE="Apache-2.0"
> 

Given that I've put significant effort in finding existing incorrect
LICENSEs, and that it included a number of your packages, may I ask why
are you adding new packages with incorrect LICENSEs?  Are you
deliberately violating the policy?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

2019-11-02 Thread Kent Fredric
On Fri, 1 Nov 2019 19:59:35 +
Michael 'veremitz' Everitt  wrote:

> Thoughts from outside peanut gallery?
> 
> Michael / veremitz.

I have an alternative that might be more pleasant:

1. Change repoman so that when its clear that:
   - There is at least one ebuild being changed
   - There is only one ebuild being changed
  Then the templated summary line is full ${P}

2. Otherwise, retain the current semantics of using a simpler
   ${P} in other cases.

3. Make no *requirements* that ${P} be used instead of ${PN},
   and that way people who think they have a good reason to use ${PN}
   instead of ${P} can do just that (if for instance, they need to lop
   off context so they can have a longer commit message )

This IMO improves things by default, given that the majority of changes
get run through repoman, and a majority of changes have very terse
requirements for extra data.

It also means that by default, when people just make the commit message
something silly like "bump", or "version bump", despite the fact they
didn't put in much effort, the log defaults to being useful, and the
commit messages relayed to #gentoo-commits improves in usefulness.

Partly, because for me, one of my prime vectors where I become aware
changes are occuring is in #gentoo commits, particularly because
something in there highlights me.

I don't want to *have* to:
- Resync my git repo 
- Dig into git wizardry 

*just* to ascertain what version was involved, and to then ascertain if
I need to investigate further.

( Because once I've already synced and started using git wizardry, I'm
already starting to pay investigation taxes )






pgpv94J0xya_W.pgp
Description: OpenPGP digital signature