The TeX Live packages under dev-texlive/* currently do not install the
man pages in the right location. They are under
/usr/share/texmf-dist/doc/man.
Install them at the right location using doman.
Having dev-texlive/* packages installing man pages requires that we
filter man pages already instal
> On Wed, 01 May 2024, Florian Schmaus wrote:
> + local grep_expressions=()
Declare f as local, too.
> + # Transform texlive_core_man_pages into grep expressions
> + # that will be used to filter out any man page that is
> +
Signed-off-by: Michał Górny
---
.github/pull_request_template.md | 12
1 file changed, 12 insertions(+)
create mode 100644 .github/pull_request_template.md
The idea is to increase awareness of the AI policy, as well as other
rules, and to inform users before they submit a PR.
Scre
Hello,
The following projects have no members right now:
https://wiki.gentoo.org/wiki/Project:ALSA
https://wiki.gentoo.org/wiki/Project:PHP
https://wiki.gentoo.org/wiki/Project:VDR
Please consider joining to keep them alive. Or disbanding them
and taking packages over directly.
--
Best regard
Since Agostino's tinderbox tests now report qa warning, the group
v...@gentoo.org has 101 open bugs assigned, most of them caused by qa
warnings from vdr-plugin-2.eclass.
Many vdr plugins need small adjustments because API or makefile changes
in upstream media-video/vdr which can be easily fixed
Maybe we could consider also adding something along the lines (4
additional positions):
1. I have emerged the package(s) on a Gentoo-based system (be it
"native" or virtualized by means of hardware-based virtualization or
system layer virtualization).
2. I have tested that the package(s) merge
On Wed, May 01, 2024 at 03:32:21PM +0200, Michał Górny wrote:
> The idea is to increase awareness of the AI policy, as well as other
> rules, and to inform users before they submit a PR.
Bit mixed feelings about this given checkboxes feel like unnecessary
churn for routine contributors and is semi
Ionen, I think that regular contributors could skip this altogether. For
example the person I'm mentoring I am sure would follow all requirements
listed by mgorny and me (see my reply).
On a side-note, I have nothing against having .github in the tree. Just
saying given I know not everyone is
On 5/1/24 10:27 AM, Maciej Barć wrote:
> Maybe we could consider also adding something along the lines (4
> additional positions):
>
> 1. I have emerged the package(s) on a Gentoo-based system (be it
> "native" or virtualized by means of hardware-based virtualization or
> system layer virtualizati
On 5/1/24 10:38 AM, Maciej Barć wrote:
> Ionen, I think that regular contributors could skip this altogether. For
> example the person I'm mentoring I am sure would follow all requirements
> listed by mgorny and me (see my reply).
Regular contributors might not even be submitting via PRs at all.
On Wed, 2024-05-01 at 16:27 +0200, Maciej Barć wrote:
> Maybe we could consider also adding something along the lines (4
> additional positions):
>
> 1. I have emerged the package(s) on a Gentoo-based system (be it
> "native" or virtualized by means of hardware-based virtualization or
> system
On Wed, 2024-05-01 at 10:28 -0400, Ionen Wolkens wrote:
> On Wed, May 01, 2024 at 03:32:21PM +0200, Michał Górny wrote:
> > The idea is to increase awareness of the AI policy, as well as other
> > rules, and to inform users before they submit a PR.
>
> Bit mixed feelings about this given checkboxe
> On Wed, 01 May 2024, Maciej Barć wrote:
> Also no license link. Afaik all contribs are under GPL-2.
That's not entirely correct. The files in the licenses/ directory
aren't, and patches in packages' files/ dirs generally follow the
license of their upstream project.
Ulrich
signature.asc
It's not obvious to me these are necessary since the entire concept
behind submitting an ebuild update is to, well, install and use it. My
base assumption is that users submitting such an update have done so
because it solved a problem for them.
This covers 1, 2, and 3, unless the user has done s
The files in the licenses/ directory
aren't, and patches in packages' files/ dirs generally follow the
license of their upstream project.
See, so it would help to have a doc that talks about the irregularities.
W dniu 1.05.2024 o 17:01, Ulrich Mueller pisze:
On Wed, 01 May 2024, Maciej Barć w
On 5/1/24 10:10 AM, Martin Dummer wrote:
> Since Agostino's tinderbox tests now report qa warning, the group
> v...@gentoo.org has 101 open bugs assigned, most of them caused by qa
> warnings from vdr-plugin-2.eclass.
>
> Many vdr plugins need small adjustments because API or makefile changes
> in
Am 01.05.24 um 16:03 schrieb Michał Górny:
The following projects have no members right now:
https://wiki.gentoo.org/wiki/Project:VDR
I am already proxy maintainer for 27 vdr packages, you can add me as
proxy maintainer to all remaining packages of v...@gentoo.org.
Or I place a PR on github f
Asking people to check 8 checkboxes is a bit much.
yea... I would pick 2. and 4. from that and put them in 1 point.
So it could be:
> [ ] I have tested that the package(s) merge inside both the user AND
net sandbox without violations on a Gentoo-based system. also, if manual
intervention (beyo
On 5/1/24 11:02 AM, Maciej Barć wrote:
> Well, not really, there were many cases where pkg was broken on sandbox!
> The latest example would be nim (before I updated it myself) where
> contributor submitted broken pkg without telling anybody. It was a WIP
> PR but nowhere they specified that it did
On Wed, 2024-05-01 at 17:12 +0200, Martin Dummer wrote:
> Am 01.05.24 um 16:03 schrieb Michał Górny:
> > The following projects have no members right now:
> >
> > https://wiki.gentoo.org/wiki/Project:VDR
> >
> I am already proxy maintainer for 27 vdr packages, you can add me as
> proxy maintainer
Maybe the solution here is that developers who merge patches from
contributors should test the PR before merging.
Of source, of course they should! (thats how the bug was discovered in
the case I recalled). It's all about communicating to the contributor
the most important things that we expec
> On Wed, 01 May 2024, Maciej Barć wrote:
>>> Also no license link. Afaik all contribs are under GPL-2.
>> That's not entirely correct. The files in the licenses/ directory
>> aren't, and patches in packages' files/ dirs generally follow the
>> license of their upstream project.
> See, so it
I agree, but such documentation doesn't belong in an ebuild repository,
but should be in a dedicated location like the Devmanual or the wiki.
From our workflow and policy standpoint - yes; but to conform how it is
mostly done in git forges like github/gitlab/codeberg etc this is also
documente
Please make a PR.
https://github.com/gentoo/gentoo/pull/36505
24 matches
Mail list logo
