Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

2019-07-24 Thread desultory
On 07/24/19 10:40, Kent Fredric wrote:
> On Tue, 23 Jul 2019 23:56:52 -0400
> desultory  wrote:
> 
>> avoid optional documentation,
>> while the proposal in question explicitly would
> 
> I assume you meant 'optional dependencies' here right? :)
> 
The user-side effects pf the proposal in question, were it to become
policy, would be that anyone seeking to not install what is presently
optional documentation would either be:
(1) wasting build time and space (and, depending on implementation,
dependencies) on their build system (potentially  masking the files from
being installed);
(2) wasting the space in their installed image(s) (if they did not mask
the files which would not currently be installed anyway); or
(3) wasting their own time working around what the developers would be
required by policy to implement by repackaging the software themselves
to avoid the time and space drawbacks (though this would generally be
expected to be a rather exceptional case, as it would be relatively
extreme to avoid what would be a distfile and some file masking from the
user side).

Developer-side effects of the proposal in question would explicitly
force developers to use bespoke workarounds to avoid adding optional
dependencies to packages, for questionable gains.

So, while I was commenting on user-side effects, the phrasing applies to
developer-side effects  given s/documentation/dependencies/.

As I have noted elsewhere, there is a solution for which the majority of
the tooling exists which could achieve the same ends as the proposal in
question without causing developers in general significant additional
overhead beyond the status quo, while as a side effect providing
additional services to users. However, the proposal in question
specifically avoids offloading the newly generated work to automated
systems in favor of, evidently, optimizing for maximum consumption of
resources with minimal standardization.



Re: [gentoo-portage-dev] [PATCH] repoman: add 'user.eclass' to deprecated eclasses

2019-07-24 Thread Zac Medico
On 7/24/19 1:16 AM, Michał Górny wrote:
> Dnia July 24, 2019 6:19:05 AM UTC, Ulrich Mueller  
> napisał(a):
>>> On Tue, 23 Jul 2019, Michał Górny wrote:
>>
>>> Make repoman report user.eclass as deprecated by GLEP 81.
>>
>> I don't understand. user.eclass is inherited by both acct-user.eclass
>> and acct-group.eclass, therefore in active use.
>>
>> Or are you planning to inline its code in the inheriting eclasses?
> 
> This doesn't trigger for indirect inherits. Unless I tested wrong.

Correct. This checks direct inherits that are parsed from the ebuild file.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: kde-misc/plasma-active-window-control

2019-07-24 Thread Andreas Sturmlechner
# Andreas Sturmlechner  (2019-07-24)
# Unmaintained and broken with current Plasma, removal in 30 days
# Bugs: https://bugs.kde.org/show_bug.cgi?id=404359,
# https://bugs.kde.org/show_bug.cgi?id=404360, see also HOMEPAGE comments
kde-misc/plasma-active-window-control






[gentoo-dev] Finalizing: GSoC-2019: BLAS/LAPACK Runtime Switching

2019-07-24 Thread Mo Zhou
Hi Gentoo Developers,

I'm finalizing the GSoC2019 project "BLAS and LAPACK runtime switch".[1]
The
documentation for user and developer is available here:

  https://wiki.gentoo.org/wiki/Blas-lapack-switch

BLAS and LAPACK are dense numerical algebra libraries of
"libc-importance" to
scientific computing users. The runtime switching mechanism enables
users to
easily switch the BLAS/LAPACK library system-wide, without recompiling
anything. A similar feature has been long-existing in Debian system, as
known
as the update-alternatives mechanism. In Gentoo we implemented this
feature
with eselect modules.

This mechanism has been tested by some users and gentoo science team
developers.
Thanks to these early testers, we've got some positive feed backs:

  https://github.com/gentoo/sci/issues/805#issuecomment-510469206
  https://github.com/gentoo/sci/issues/805#issuecomment-512097570

I sincerely invite users and developers who heavily rely on BLAS/LAPACK
libraries to test it. Should you find any problem, or have any
suggestion/question, please let me know :-)

[1]
https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2019/Ideas/BLAS_and_LAPACK_runtime_switching



Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

2019-07-24 Thread Kent Fredric
On Tue, 23 Jul 2019 23:56:52 -0400
desultory  wrote:

> avoid optional documentation,
> while the proposal in question explicitly would

I assume you meant 'optional dependencies' here right? :)



pgp36j4n0ZoM_.pgp
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] repoman: add 'user.eclass' to deprecated eclasses

2019-07-24 Thread Michał Górny
Dnia July 24, 2019 6:19:05 AM UTC, Ulrich Mueller  napisał(a):
>> On Tue, 23 Jul 2019, Michał Górny wrote:
>
>> Make repoman report user.eclass as deprecated by GLEP 81.
>
>I don't understand. user.eclass is inherited by both acct-user.eclass
>and acct-group.eclass, therefore in active use.
>
>Or are you planning to inline its code in the inheriting eclasses?

This doesn't trigger for indirect inherits. Unless I tested wrong.

>
>Ulrich


--
Best regards, 
Michał Górny



Re: [gentoo-portage-dev] [PATCH] repoman: add 'user.eclass' to deprecated eclasses

2019-07-24 Thread Ulrich Mueller
> On Tue, 23 Jul 2019, Michał Górny wrote:

> Make repoman report user.eclass as deprecated by GLEP 81.

I don't understand. user.eclass is inherited by both acct-user.eclass
and acct-group.eclass, therefore in active use.

Or are you planning to inline its code in the inheriting eclasses?

Ulrich


signature.asc
Description: PGP signature