Re: [gentoo-dev] [PATCH cmake-multilib] Use multilib-minimal phase functions.

2014-05-09 Thread Michał Górny
Dnia 2014-04-30, o godz. 20:14:35
Michał Górny  napisał(a):

> The goal is to make overriding parts of build process easy. Before,
> the eclass called cmake-utils directly via multilib_foreach_abi,
> therefore user overriding a phase function needed to call
> multilib_foreach_abi himself, and likely define another function with
> the details.

Committed.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


[gentoo-dev] Re: Banning modification of pkg-config files (was: [gentoo-project] Re: Call For Agenda Items - 13 May 2014)

2014-05-09 Thread Matti Bickel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/09/2014 04:07 PM, hasufell wrote:
> I ask the council to vote on banning pkg-config files that would
> be added or renamed downstream (at least this will prevent new
> violations).

I want to repeat my stance from the linked bug that making this a
policy or calling on council to add more weight to existing devmanual
bits is adding red tape that from my point of view decreases the
quality of Gentoo. Asking me to remove the pkg-config file for lua-5.2
or removing the modifications to 5.1 will kill support for packages
depending on these files existing.

As long as there's stuff expecting the file to be around, I have a
hard time committing a "fix" that will increase the breakage in the tree.

Let me be clear: once packagers of lua using apps tell me they no
longer need the .pc file for their stuff to work, I'll remove it
promptly or switch to the reduced version you get from calling "make
pc" for lua-5.2.

However, all the linked bugs and commits seem to address the point
that debian *renames* the lua .pc files. You seam to take particular
issue with slotting lua (which requires us to rename them as well).

I'm on the record saying that I don't like this solution. However,
I've made it clear (and the eselect-lua module implements this) that
there's always a lua.pc, liblua.so, etc of the user's chosing. It's
also the only thing we got to resolve the stalemate of lua users
lagging behind releases. If you have better ideas, please let me know.

Since this is a technical matter, please direct further discussion to
the gentoo-dev ML.

Cheers, Matti
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTbRyhXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNzE1M0M4QzQxMzM4REREMjMzQjg4NUZE
REY5NzFGMTE4RUVBNUU2AAoJEN35cfEY7qXmEGsP/39WprTJ9T4FmBiNO+xnPDS5
H3FbNmdN/YjyOy5OSBMbS2j9fxQXEJ5AdAeE5gWyEiNEji0wmecWqP2FNAEtoZ5c
H4IJ92eSyw99zz424GU2eS0uNCkujn/xOIxWHmrvWiCiUYzF150KHl9nrRRdRrwB
dKjyz7nXiEyZDS1dQ4gyTMeA6mUIrr0bFl0G8Kfy0dPWB0elpe837no/S/fRcKtM
syb9+QL3TvYlCVbONkcFxtOQyij+9OTcMffITVysiHjy5+CNKoVjw3zKUPoYQN1f
CSdob9x/W+vUrZt1gjEbxukqyBMlBokapvN1nwwi7T6IczHCPpDtnvN6TncX/0VW
AkwB5wAgtxjsf6bu8vvx6D6gRYDoYFgXHe81m+SHfmbkDaIAUk67QdN3WHg4R0o7
fgJ5KVx5KowemNdM3SybJlTTOkt6ROaqkzMRsXDC+vDwQEZ4881zLpttGFfEJPjR
tfej+FrhoMv5yir8joUIePwXLXluF1D0DO8RlrUpGTAFkwY1QqdA0ho3rwRpDZDT
70iWKepz6Xgj7mKlVjSF6C5iPxyKYMbgVgH+4IK4MCWYvam/tLwtbuegDmF/txUM
5P4a4fQUzvmGFmDOkRsnJBj5Gnez8J5DxzB3hmRJgT+TVKxlfRCQ4Ajh31VHQXun
nw5cxcrYETn9jQtdmbqJ
=JnYK
-END PGP SIGNATURE-



[gentoo-dev] Re: Banning modification of pkg-config files

2014-05-09 Thread Markos Chandras
Hi,

(please avoid cross-list e-mails in the future if possible. Makes
threading horrible)

On 05/09/2014 07:21 PM, Matti Bickel wrote:
> On 05/09/2014 04:07 PM, hasufell wrote:
>> I ask the council to vote on banning pkg-config files that would
>> be added or renamed downstream (at least this will prevent new
>> violations).
> 
> I want to repeat my stance from the linked bug that making this a
> policy or calling on council to add more weight to existing devmanual
> bits is adding red tape that from my point of view decreases the
> quality of Gentoo. Asking me to remove the pkg-config file for lua-5.2
> or removing the modifications to 5.1 will kill support for packages
> depending on these files existing.
> [...]

I was wondering, is there a good reason we keep our own pkgconfig files
instead of communicating that to upstream and resolve that properly?
What other distributions do? Or are we a special case and we need our
own pc files?

-- 
Regards,
Markos Chandras



Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-09 Thread Tom Wijsman
On Fri, 09 May 2014 20:57:29 +0100
Markos Chandras  wrote:

> I was wondering, is there a good reason we keep our own pkgconfig
> files instead of communicating that to upstream and resolve that
> properly?

Yes, when your "instead of ..." is not an option.

> What other distributions do? Or are we a special case and
> we need our own pc files?

No, see https://bugs.gentoo.org/show_bug.cgi?id=509392#c23 which reads:

"You do realize that out of five distros (Fedora, Debian,
Slackware, SuSe, Mandriva) I checked five ship a .pc file?" by mabi.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-09 Thread Markos Chandras
On 05/09/2014 09:08 PM, Tom Wijsman wrote:
> On Fri, 09 May 2014 20:57:29 +0100
> Markos Chandras  wrote:
> 
>> I was wondering, is there a good reason we keep our own pkgconfig
>> files instead of communicating that to upstream and resolve that
>> properly?
> 
> Yes, when your "instead of ..." is not an option.

Why not? If the package does not work out of the box then something is
broken upstream? If it works for Debian but not for us then maybe we do
something wrong? Otherwise, if having our own pc files (assuming there
is no abuse here and we touch reverse deps only when really necessary)
why is that a problem?

I fail to understand the problem here.

> 
>> What other distributions do? Or are we a special case and
>> we need our own pc files?
> 
> No, see https://bugs.gentoo.org/show_bug.cgi?id=509392#c23 which reads:
> 
> "You do realize that out of five distros (Fedora, Debian,
> Slackware, SuSe, Mandriva) I checked five ship a .pc file?" by mabi.
> 

I am not talking about Lua here. It's a more general question.

-- 
Regards,
Markos Chandras



Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-09 Thread Rich Freeman
On Fri, May 9, 2014 at 4:08 PM, Tom Wijsman  wrote:
> On Fri, 09 May 2014 20:57:29 +0100
> Markos Chandras  wrote:
>
>> I was wondering, is there a good reason we keep our own pkgconfig
>> files instead of communicating that to upstream and resolve that
>> properly?
>
> Yes, when your "instead of ..." is not an option.
>
>> What other distributions do? Or are we a special case and
>> we need our own pc files?
>
> No, see https://bugs.gentoo.org/show_bug.cgi?id=509392#c23 which reads:
>
> "You do realize that out of five distros (Fedora, Debian,
> Slackware, SuSe, Mandriva) I checked five ship a .pc file?" by mabi.

I think fixing upstream is a no-brainer.  The controversy only exists
when upstream refuses to cooperate (which seems to be the case when
we're one of six distros patching it).  If there are other situations
where we supply our own files please speak up.

When the only issue is maintainer laziness I could see fixing that in
a different way...

Rich



Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-09 Thread Tom Wijsman
On Fri, 09 May 2014 21:10:50 +0100
Markos Chandras  wrote:

> On 05/09/2014 09:08 PM, Tom Wijsman wrote:
> > On Fri, 09 May 2014 20:57:29 +0100
> > Markos Chandras  wrote:
> > 
> >> I was wondering, is there a good reason we keep our own pkgconfig
> >> files instead of communicating that to upstream and resolve that
> >> properly?
> > 
> > Yes, when your "instead of ..." is not an option.
> 
> Why not? If the package does not work out of the box then something is
> broken upstream?

Some upstreams don't care about Gentoo's practices like slotting and/or
dynamic linking; similarly, similar practices on other distributions.

> If it works for Debian but not for us then maybe we do something
> wrong?

This mixes two things. It currently works for the Lua maintainers, as
those pkgconfig files are present; just like they are present on Debian.

> >> What other distributions do? Or are we a special case and
> >> we need our own pc files?
> > 
> > No, see https://bugs.gentoo.org/show_bug.cgi?id=509392#c23 which
> > reads:
> > 
> > "You do realize that out of five distros (Fedora, Debian,
> > Slackware, SuSe, Mandriva) I checked five ship a .pc file?" by
> > mabi.
> > 
> 
> I am not talking about Lua here. It's a more general question.

Ah, I see; it's just that we come from the Lua context background, so
it'll often be used as example. As for in general, we'll indeed need to
investigate what other distributions do; but, Lua is that special case.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-09 Thread Tom Wijsman
On Fri, 9 May 2014 16:15:58 -0400
Rich Freeman  wrote:

> I think fixing upstream is a no-brainer.

It indeed is, this is the goal; you can force them in multiple ways,
some of which can be found on the Lua bug and previous discussion(s).

> The controversy only exists when upstream refuses to cooperate (which
> seems to be the case when we're one of six distros patching it).  If
> there are other situations where we supply our own files please speak
> up.

Not that I know of; the refusal to cooperate is what this is all about,
see my last response to hwoarang before this mail for a short summary.
Though, I think that the Lua maintainers can explain all the details...

> When the only issue is maintainer laziness I could see fixing that in
> a different way...

It has always been an issue; we could always use more manpower, ...

https://wiki.gentoo.org/wiki/Contributing_to_Gentoo

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-09 Thread Markos Chandras
On 05/09/2014 09:32 PM, Tom Wijsman wrote:
> On Fri, 9 May 2014 16:15:58 -0400
> Rich Freeman  wrote:
> 
>> I think fixing upstream is a no-brainer.
> 
> It indeed is, this is the goal; you can force them in multiple ways,
> some of which can be found on the Lua bug and previous discussion(s).
> 
>> The controversy only exists when upstream refuses to cooperate (which
>> seems to be the case when we're one of six distros patching it).  If
>> there are other situations where we supply our own files please speak
>> up.
> 
> Not that I know of; the refusal to cooperate is what this is all about,
> see my last response to hwoarang before this mail for a short summary.
> Though, I think that the Lua maintainers can explain all the details...
> 
>> When the only issue is maintainer laziness I could see fixing that in
>> a different way...
> 
> It has always been an issue; we could always use more manpower, ...
> 
> https://wiki.gentoo.org/wiki/Contributing_to_Gentoo
> 

Well to me it feels that gentoo specific .pc files is a similar problem
to any other patch that affects upstream code in order to make the
package compatible with gentoo. Some people may consider downstream pc
files more dangerous because reverse deps are affected. But really, if
there is no other alternative, we shouldn't be treating this as a
special case. We patch upstream packages all the time after all

-- 
Regards,
Markos Chandras



Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-09 Thread Ben de Groot
On 10 May 2014 04:34, Markos Chandras  wrote:
> On 05/09/2014 09:32 PM, Tom Wijsman wrote:
>> On Fri, 9 May 2014 16:15:58 -0400
>> Rich Freeman  wrote:
>>
>>> I think fixing upstream is a no-brainer.
>>
>> It indeed is, this is the goal; you can force them in multiple ways,
>> some of which can be found on the Lua bug and previous discussion(s).
>>
>>> The controversy only exists when upstream refuses to cooperate (which
>>> seems to be the case when we're one of six distros patching it).  If
>>> there are other situations where we supply our own files please speak
>>> up.
>>
>> Not that I know of; the refusal to cooperate is what this is all about,
>> see my last response to hwoarang before this mail for a short summary.
>> Though, I think that the Lua maintainers can explain all the details...
>>
>>> When the only issue is maintainer laziness I could see fixing that in
>>> a different way...
>>
>> It has always been an issue; we could always use more manpower, ...
>>
>> https://wiki.gentoo.org/wiki/Contributing_to_Gentoo
>>
>
> Well to me it feels that gentoo specific .pc files is a similar problem
> to any other patch that affects upstream code in order to make the
> package compatible with gentoo. Some people may consider downstream pc
> files more dangerous because reverse deps are affected. But really, if
> there is no other alternative, we shouldn't be treating this as a
> special case. We patch upstream packages all the time after all

Exactly. I don't understand why this is an issue at all. Obviously,
if upstream does not ship a .pc file or ships a broken one, we try
to work with upstream to get it fixed on their end. If they are
uncooperative, we fix it on our end.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-09 Thread Alexandre Rostovtsev
On Sat, 2014-05-10 at 13:50 +0800, Ben de Groot wrote:
> On 10 May 2014 04:34, Markos Chandras  wrote:
> > On 05/09/2014 09:32 PM, Tom Wijsman wrote:
> >> On Fri, 9 May 2014 16:15:58 -0400
> >> Rich Freeman  wrote:
> >>
> >>> I think fixing upstream is a no-brainer.
> >>
> >> It indeed is, this is the goal; you can force them in multiple ways,
> >> some of which can be found on the Lua bug and previous discussion(s).
> >>
> >>> The controversy only exists when upstream refuses to cooperate (which
> >>> seems to be the case when we're one of six distros patching it).  If
> >>> there are other situations where we supply our own files please speak
> >>> up.
> >>
> >> Not that I know of; the refusal to cooperate is what this is all about,
> >> see my last response to hwoarang before this mail for a short summary.
> >> Though, I think that the Lua maintainers can explain all the details...
> >>
> >>> When the only issue is maintainer laziness I could see fixing that in
> >>> a different way...
> >>
> >> It has always been an issue; we could always use more manpower, ...
> >>
> >> https://wiki.gentoo.org/wiki/Contributing_to_Gentoo
> >>
> >
> > Well to me it feels that gentoo specific .pc files is a similar problem
> > to any other patch that affects upstream code in order to make the
> > package compatible with gentoo. Some people may consider downstream pc
> > files more dangerous because reverse deps are affected. But really, if
> > there is no other alternative, we shouldn't be treating this as a
> > special case. We patch upstream packages all the time after all
> 
> Exactly. I don't understand why this is an issue at all. Obviously,
> if upstream does not ship a .pc file or ships a broken one, we try
> to work with upstream to get it fixed on their end. If they are
> uncooperative, we fix it on our end.

Adding a pkgconfig file is a bit of a special case. Some distros have a
habit of renaming and creating .pc files for various libraries. But in
Gentoo, almost all pkgconfig files come from upstream with minimal
modification. So a .pc file that is specific to Gentoo is a rare
exception, and it could cause confusion for users who installed Gentoo
on their development machine and who wish to develop new portable
software.

Of course, in the case of Lua, it seems that all other distros are
already providing .pc files, so joining them would seem to be the
correct thing to do (we would simply be recognizing a de facto
standard).


signature.asc
Description: This is a digitally signed message part