Re: [gentoo-dev] [PATCH 1/2] Document policy of not relying on implicit eclass inherits

> On Wed, 25 Feb 2015, hasufell wrote: >>> +As an example: if you use epatch in your ebuild, you must >>> +inherit eutils.eclass directly, even if another eclass (like >>> distutils-r1) >>> +already inherits it. Exceptions to this policy must be discussed and >>> documented. >>> + >> >> Do

Re: [gentoo-dev] [RFC] luajit global useflag

В письме от Чт, 26 февраля 2015 13:36:24 пользователь Ben de Groot написал: > I propose we make luajit a global useflag, using the description from > media-sound/csound: > > Use the lua just-in-time compiler dev-lang/luajit instead > of dev-lang/lua Voting up! Although, I'd also propose lua.ecl

[gentoo-dev] [RFC] luajit global useflag

% quse -D luajit local:luajit:app-editors/gvim: Use dev-lang/luajit instead of dev-lang/lua local:luajit:app-editors/vim: Use dev-lang/luajit instead of dev-lang/lua local:luajit:app-editors/vim-qt: Use dev-lang/luajit instead of dev-lang/lua local:luajit:games-action/minetest: Use dev-lang/lu

[gentoo-dev] Re: why is a line in /usr/portage/profiles/base/package.use.mask ignored?

Alan McKinnon posted on Wed, 25 Feb 2015 14:00:57 +0200 as excerpted: > Why are you messing around with the profile anyway, when all the > available documentation in many many places tells you to set your chosen > USE for specific packages in package.use? I believe you missed his email address, @

Re: [gentoo-dev] [PATCH] qmake-utils.eclass: add qt{4,5}_get_bindir helper functions

On 20 February 2015 at 04:06, Jeroen Roovers wrote: > On Wed, 18 Feb 2015 19:58:29 +0800 > Ben de Groot wrote: > >> The attached patch proposes two helper functions to be added to >> qmake-utils.eclass. These functions echo the correct directory where >> qt binaries such as moc and lrelease are l

Re: [gentoo-dev] do we need special elog messages for bindist?

On Wed, Feb 25, 2015 at 1:38 PM, Mike Gilbert wrote: > > > I would like to remove the elog for a couple of reasons: > > 1. The use flag description is there for whoever cares to read it. > There is no need to alert the user every time. > 2. We are not lawyers, and I have no business giving legal a

Re: [gentoo-dev] do we need special elog messages for bindist?

On Wed, Feb 25, 2015 at 1:17 PM, "Paweł Hajdan, Jr." wrote: > I'm looking at which > suggests removing elog messages chromium has for bindist: > > This is the snippet we use in the ebuild: > > if use bindist; then > elog "bin

[gentoo-dev] do we need special elog messages for bindist?

I'm looking at which suggests removing elog messages chromium has for bindist: This is the snippet we use in the ebuild: if use bindist; then elog "bindist enabled: H.264 video support will be disabled." else

Re: [gentoo-dev] [PATCH 1/2] Document policy of not relying on implicit eclass inherits

On 02/25/2015 05:55 PM, Ulrich Mueller wrote: >> On Wed, 25 Feb 2015, Julian Ospald wrote: > >> + >> +You must not rely on provided functions of implicitly inherited eclasses. > > Not sure if this can be stated as a general policy. For example, if > your ebuild inherits elisp.eclass then it i

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

> On Wed, 25 Feb 2015, Diamond wrote: > It looks like I can't edit > https://wiki.gentoo.org/wiki/Project:Games/Ebuild_howto, is it a > bug? You can't because it is a project page. But I think you can leave a message there on the talk page. > gamesenv function looks outdated there. This fun

Re: [gentoo-dev] [PATCH 1/2] Document policy of not relying on implicit eclass inherits

> On Wed, 25 Feb 2015, Julian Ospald wrote: > + > +You must not rely on provided functions of implicitly inherited eclasses. Not sure if this can be stated as a general policy. For example, if your ebuild inherits elisp.eclass then it is pointless to inherit also elisp-common.eclass, because

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

On Wed, 25 Feb 2015 16:44:28 +0100 hasufell wrote: > So if a project ignores the community, the council, the QA team AND > violates GLEP39, we allow that, because they still do commits? It looks like I can't edit https://wiki.gentoo.org/wiki/Project:Games/Ebuild_howto, is it a bug? gamesenv func

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

On Wed, Feb 25, 2015 at 10:52 AM, hasufell wrote: > >> What specific action are you advocating for which hasn't been done? >> > > Start with enforcing GLEP39 which is still violated. > I said "specific" - what do you mean by "enforcing GLEP39?" -- Rich

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

On 02/25/2015 04:47 PM, Rich Freeman wrote: > On Wed, Feb 25, 2015 at 10:44 AM, hasufell wrote: >> On 02/21/2015 10:16 PM, Andreas K. Huettel wrote: >>> Am Samstag, 21. Februar 2015, 20:16:31 schrieb hasufell: >>> What did the council say again about the functionality of the team? What's

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

On Wed, Feb 25, 2015 at 10:44 AM, hasufell wrote: > On 02/21/2015 10:16 PM, Andreas K. Huettel wrote: >> Am Samstag, 21. Februar 2015, 20:16:31 schrieb hasufell: >> >>> What did the council say again about the functionality of the team? >>> What's the argumentation to not do anything, except decid

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

On 02/21/2015 10:16 PM, Andreas K. Huettel wrote: > Am Samstag, 21. Februar 2015, 20:16:31 schrieb hasufell: > >> What did the council say again about the functionality of the team? >> What's the argumentation to not do anything, except deciding policies >> over it's head? > > functionality != wi

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

On 02/21/2015 10:16 PM, Andreas K. Huettel wrote: > Am Samstag, 21. Februar 2015, 20:16:31 schrieb hasufell: > >> What did the council say again about the functionality of the team? >> What's the argumentation to not do anything, except deciding policies >> over it's head? > > functionality != wi

[gentoo-dev] [PATCH 2/2] Fix spelling

--- ebuild-writing/using-eclasses/text.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ebuild-writing/using-eclasses/text.xml b/ebuild-writing/using-eclasses/text.xml index 49ec23b..b54f559 100644 --- a/ebuild-writing/using-eclasses/text.xml +++ b/ebuild-writing/using-ecla

[gentoo-dev] [PATCH 1/2] Document policy of not relying on implicit eclass inherits

--- ebuild-writing/using-eclasses/text.xml | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/ebuild-writing/using-eclasses/text.xml b/ebuild-writing/using-eclasses/text.xml index de9ec7f..49ec23b 100644 --- a/ebuild-writing/using-eclasses/text.xml +++ b/ebuild-writing/

[gentoo-dev] [PATCH 0/2] devmanual patches

Since bug #540916 I have the feeling it is not clear to all developers that we must not rely on implicit eclass inherits. This has caused problems and breakage in the past and was even discussed in my recruitment process. If there are exeptions to this policy, then they have to be discussed and d

Re: [gentoo-dev] why is a line in /usr/portage/profiles/base/package.use.mask ignored?

On Wed, Feb 25, 2015 at 5:23 AM, wrote: > Hello *, > > dev-lisp/ecls-15.2.21 does not compiled with USE=cpu_flags_x86_sse. So, > I've added the line > > =dev-lisp/ecls-15.2.21 cpu_flags_x86_sse > > to .../profiles/base/package.use.mask. But I still see > > dns ~ # emerge -pv dev-lisp/ecls > [ebui

Re: [gentoo-dev] why is a line in /usr/portage/profiles/base/package.use.mask ignored?

On Wed, 25 Feb 2015 17:23:03 +0600 (NOVT) gro...@gentoo.org wrote: > Hello *, > > dev-lisp/ecls-15.2.21 does not compiled with USE=cpu_flags_x86_sse. > So, I've added the line > > =dev-lisp/ecls-15.2.21 cpu_flags_x86_sse > > to .../profiles/base/package.use.mask. But I still see > > dns ~ # em

[gentoo-dev] why is a line in /usr/portage/profiles/base/package.use.mask ignored?

Hello *, dev-lisp/ecls-15.2.21 does not compiled with USE=cpu_flags_x86_sse. So, I've added the line =dev-lisp/ecls-15.2.21 cpu_flags_x86_sse to .../profiles/base/package.use.mask. But I still see dns ~ # emerge -pv dev-lisp/ecls [ebuild R] dev-lisp/ecls-15.2.21:0/15.2.21::gentoo [15.