On 10/01/2024 16.10, Ulrich Mueller wrote:
On Wed, 10 Jan 2024, Florian Schmaus wrote:
On 10/01/2024 14.58, Ulrich Mueller wrote:
Looks like readme.gentoo-r1 already gives you control over this:
# If you want to show them always, please set FORCE_PRINT_ELOG to a non empty
# value in your ebui
> On Wed, 10 Jan 2024, Florian Schmaus wrote:
> On 10/01/2024 14.58, Ulrich Mueller wrote:
>> Looks like readme.gentoo-r1 already gives you control over this:
>> # If you want to show them always, please set FORCE_PRINT_ELOG to a non empty
>> # value in your ebuild before this function is call
On 10/01/2024 14.58, Ulrich Mueller wrote:
On Wed, 10 Jan 2024, Florian Schmaus wrote:
On 10/01/2024 12.04, Sam James wrote:
1) The name seems odd (why not readme.gentoo-r2)?
2) Why can't the existing eclass be improved?
Both points, the name of the eclass and the question if this should b
> On Wed, 10 Jan 2024, Florian Schmaus wrote:
> On 10/01/2024 12.04, Sam James wrote:
>> 1) The name seems odd (why not readme.gentoo-r2)?
>> 2) Why can't the existing eclass be improved?
> Both points, the name of the eclass and the question if this should be
> added to the existing eclass o
On 10/01/2024 12.04, Sam James wrote:
Florian Schmaus writes:
I really like the functionality of readme.gentoo-r1.eclass, as it
allows to communicate Gentoo-specific information about a package to
the user. Especially as it improves the signal-to-noise ratio of
messages arriving to our users.
Florian Schmaus writes:
> I really like the functionality of readme.gentoo-r1.eclass, as it
> allows to communicate Gentoo-specific information about a package to
> the user. Especially as it improves the signal-to-noise ratio of
> messages arriving to our users.
>
> However, readme.gentoo-r1.e
On 09/01/2024 11.43, Michał Górny wrote:
On Tue, 2024-01-09 at 11:39 +0100, Florian Schmaus wrote:
Even if we say it is the user's fault, then the problem of handling a
decompressor failure would still exist. The eclass does not gracefully
continue when decompressing the doc file, but instead it
On Tue, 2024-01-09 at 11:39 +0100, Florian Schmaus wrote:
> Even if we say it is the user's fault, then the problem of handling a
> decompressor failure would still exist. The eclass does not gracefully
> continue when decompressing the doc file, but instead it runs into a
> die(). To address th
On 09/01/2024 10.59, Michał Górny wrote:
On Tue, 2024-01-09 at 09:30 +0100, Florian Schmaus wrote:
On 06/01/2024 18.21, Michał Górny wrote:
On Sat, 2024-01-06 at 18:01 +0100, Florian Schmaus wrote:
I really like the functionality of readme.gentoo-r1.eclass, as it
allows to communicate Gentoo-s
On Tue, 2024-01-09 at 09:30 +0100, Florian Schmaus wrote:
> On 06/01/2024 18.21, Michał Górny wrote:
> > On Sat, 2024-01-06 at 18:01 +0100, Florian Schmaus wrote:
> > > I really like the functionality of readme.gentoo-r1.eclass, as it
> > > allows to communicate Gentoo-specific information about a
On 06/01/2024 18.21, Michał Górny wrote:
On Sat, 2024-01-06 at 18:01 +0100, Florian Schmaus wrote:
I really like the functionality of readme.gentoo-r1.eclass, as it
allows to communicate Gentoo-specific information about a package to
the user. Especially as it improves the signal-to-noise ratio
On Sat, 2024-01-06 at 18:01 +0100, Florian Schmaus wrote:
> I really like the functionality of readme.gentoo-r1.eclass, as it
> allows to communicate Gentoo-specific information about a package to
> the user. Especially as it improves the signal-to-noise ratio of
> messages arriving to our users.
>
I really like the functionality of readme.gentoo-r1.eclass, as it
allows to communicate Gentoo-specific information about a package to
the user. Especially as it improves the signal-to-noise ratio of
messages arriving to our users.
However, readme.gentoo-r1.eclass will only show this information o
13 matches
Mail list logo
