[gentoo-dev] RFC: UID/GID assignment for tss (59)
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)
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
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
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/
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
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
