date:20130303

On Mar 3, 2013 2:42 AM, Peter Stuge pe...@stuge.se wrote:

 Markos Chandras wrote:
  it just feels strange

 I hear they call it getting stuff done..


 //Peter

good thing you are not a dev then.
Thanks for the heads up in case you ever want to become one

Re: [gentoo-dev] [RFC] multilib-build.eclass and restricting unsupported ABIs

On Sun, 3 Mar 2013 00:02:30 +0100
Michał Górny mgo...@gentoo.org wrote:

 Hello,
 
 With the introduction of support for x32 ABI it has become necessary
 to enhance the multilib-build eclass with some kind of support for
 specifying the supported/unsupported ABIs.
 
 In this particular context, tetromino has noted that many packages
 don't support the x32 ABI. From the ones currently using the eclass,
 the one is app-emulation/wine.
 
 I would like to enhance the eclass with the ability to specify
 supported and unsupported ABIs. For that reason, I'd like to gather
 your opinion on what would be the best solution. Preferably, I'd see
 one that could work both for the eclass and multilib-portage so that
 we wouldn't need to duplicate the same information.
 
 
 1) opt-in or opt-out?
 
 So far, the multilib-capable packages did get support for all multilib
 ABIs on given architecture enabled (assuming that the package is
 keyworded for the arch).
 
 As a next step from that, I think an opt-out solution be the simplest
 and most consistent one. In this particular context:
 
   MULTILIB_RESTRICT_ABIS=( ... )
 
 which would be an optional variable disabling support for problematic
 ABIs in the packages which need it.
 
 
 An alternative solution would be an opt-in like in python-r1:
 
   MULTILIB_COMPAT=( ... )
 
 but so far, that would mean that all current packages will have to be
 updated to list the currently supported ABIs. And it all sucks a bit
 due to the gray zone between amd64/x86 keyword and ABIs.
 
 
 And no, optional MULTILIB_COMPAT is a no-go. It's a weird breed of
 opt-in and opt-out which is just awful.


I'd go for opt-out (MULTILIB_RESTRICT_ABIS); Ideally we'd want all
packages to support all abis, so what we should aim at is building
for every abi. Also, opt-in has the big disadvantage that introducing a
new abi requires a lot of tree-wide changes, which we tried to avoid
since the beginning.


 2) USE flag names or ABI names?
 
 Next thing to decide would be: whether the restrict should specify USE
 flag names (like the eclass solution) or ABI names (like
 portage-multilib and profiles).
 
 The advantage of USE flags is that they are guaranteed to be unique
 and clear. As in, two arches won't ever have the same USE flag for ABI
 with the same name.
 
   MULTILIB_RESTRICT_ABIS=( abi_x86_x32 )
 
 The advantage of ABI names is that multilib-portage is aware of them.
 So, it's mostly about supporting a poor choice done without consulting
 other developers.
 
   MULTILIB_RESTRICT_ABIS=( x32 )
 
 The problem with that is that a new arch can define an ABI with
 exactly the same name (since all ABI variables are profile-local). In
 that case, the restriction will unexpectedly apply to that arch.
 
 
 By the way, maybe we should move the flag - ABI mapping from
 the eclass to some global location in profiles? That would make it
 possible to use the global flags from multilib-portage as well.
 
 What are your thoughts?

I'd prefer the useflag names for the sake of unicity, but I'm not sure
I understand why and how multilib-portage needs it.
What will multilib-portage uses it for ? If that's to gather and use
its  information to restrict some ABIs, then I assume you will have
something like 'if multilib-portage then dont do anything multilib' in
the eclass; well, you can very well export a variable translating the
useflag names to abi names that multilib-portage can use too. I'm not
sure you need the mapping on the profiles.

A.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog

2013-03-03 Thread Tomáš Chvátal

If I remember correctly the damn rule is to put it for 30 days into
testing, and as you said there was no previous version on arm so users
could've reported some issues, i agree that sometimes you have to ignore
the rules to really fix stable, but was this such case for sure?
Dne 3.3.2013 3:43 Mike Frysinger vap...@gentoo.org napsal(a):

 On Saturday 02 March 2013 21:01:39 Markos Chandras wrote:
  On Mar 3, 2013 1:55 AM, Mike Frysinger vap...@gentoo.org wrote:
   complain to me when all these arm systems that totally had confuse
   already installed go down in fire.  it literally makes 0 difference
   here.
 
  Why would they have it installed (in stable) if it had no keywords? and
 if
  it is such an important package why it didn't have testing keywords in
 the
  first place? I did't say it broke something, it just feels strange and
 this
  is why I asked

 sounds like there's no further clarification necessary
 -mike

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog

2013-03-03 Thread Peter Stuge

Markos Chandras wrote:
   it just feels strange
 
  I hear they call it getting stuff done..
 
 good thing you are not a dev then.
 Thanks for the heads up in case you ever want to become one

I explain to you what happened and you, a recruiter, proceed to
threaten me in case I want to become a developer.

And people wonder if anything is wrong with Gentoo recruitment..


Back on topic: It seems that you must immediately retire Mike.

(Or the rule..)


//Peter

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog

On 3 March 2013 12:01, Peter Stuge pe...@stuge.se wrote:
 Markos Chandras wrote:
   it just feels strange
 
  I hear they call it getting stuff done..

 good thing you are not a dev then.
 Thanks for the heads up in case you ever want to become one

 I explain to you what happened

getting stuff done is not an answer. I still don't understand why
stable keywords had to be added directly. Do you understand why Mike
did that
or just playing smart here? Instead of you giving me cryptic and
smart answers, you could have explained to me why it was necessary
and job done.

 and you, a recruiter, proceed to threaten me in case I want to become a 
 developer.

 And people wonder if anything is wrong with Gentoo recruitment..


If you can't play by the rules, either try to change them or go away
or at least try to explain why you break them.

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] [RFC] multilib-build.eclass and restricting unsupported ABIs

2013-03-03 Thread Michał Górny

On Sun, 3 Mar 2013 12:41:07 +0100
Alexis Ballier aball...@gentoo.org wrote:

 I'd prefer the useflag names for the sake of unicity, but I'm not sure
 I understand why and how multilib-portage needs it.

Well, I mostly thought that if we were to introduce that information,
multilib-portage could use it as well rather than expecting
the information to be duplicated for the sake of it.

Not that I see a good reason for multilib-portage to work-around our
multilib but they like it.

 What will multilib-portage uses it for ? If that's to gather and use
 its  information to restrict some ABIs, then I assume you will have
 something like 'if multilib-portage then dont do anything multilib' in
 the eclass; well, you can very well export a variable translating the
 useflag names to abi names that multilib-portage can use too. I'm not
 sure you need the mapping on the profiles.

Well, right now multilib-portage is using the 'fallback' mechanism
in the eclass (the same as used on non-multilib arches). They mask all
the multilib flags and build the package one ABI at a time. The foreach
loop does not find any enabled flag and uses ${ABI:-${DEFAULT_ABI}}.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog

2013-03-03 Thread Peter Stuge

Markos Chandras wrote:
  I explain to you what happened
 
 getting stuff done is not an answer. I still don't understand why
 stable keywords had to be added directly. Do you understand why Mike
 did that or just playing smart here?

To me it's obvious that he did it because it made something easier
for him. By breaking the Gentoo rule he got something done.


 Instead of you giving me cryptic and smart answers, you could
 have explained to me why it was necessary and job done.

I have no idea what exactly became easier for him, and what it is may
be none of our business.


  and you, a recruiter, proceed to threaten me in case I want to become a 
  developer.
 
  And people wonder if anything is wrong with Gentoo recruitment..
 
 If you can't play by the rules, either try to change them or go away
 or at least try to explain why you break them.

Again, I guess you have to make Mike go away now.


On rules:

It's very easy to create bad rules while having the best intentions.
The road to hell is paved with good intentions.

It takes immense effort to change such rules, and an establishment
which has grown fond of them. It sadly seems much easier to maintain
a whole separate portage tree than to fix broken rules. :\

That said, I don't know what route I'll choose if I ever have to.


//Peter

[gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs

Michał Górny schrieb:
 Hello,
 
 With the introduction of support for x32 ABI it has become necessary to
 enhance the multilib-build eclass with some kind of support for
 specifying the supported/unsupported ABIs.
 
 In this particular context, tetromino has noted that many packages
 don't support the x32 ABI. From the ones currently using the eclass,
 the one is app-emulation/wine.
 
 I would like to enhance the eclass with the ability to specify
 supported and unsupported ABIs. For that reason, I'd like to gather
 your opinion on what would be the best solution. Preferably, I'd see
 one that could work both for the eclass and multilib-portage so that we
 wouldn't need to duplicate the same information.
 
 
 1) opt-in or opt-out?
 
 So far, the multilib-capable packages did get support for all multilib
 ABIs on given architecture enabled (assuming that the package is
 keyworded for the arch).
 
 As a next step from that, I think an opt-out solution be the simplest
 and most consistent one. In this particular context:
 
   MULTILIB_RESTRICT_ABIS=( ... )
 
 which would be an optional variable disabling support for problematic
 ABIs in the packages which need it.

+1 for this one, better disable support for some packages with reported
issues then having to update all packages, when an ABI is added.

 
 
 An alternative solution would be an opt-in like in python-r1:
 
   MULTILIB_COMPAT=( ... )
 
 but so far, that would mean that all current packages will have to be
 updated to list the currently supported ABIs. And it all sucks a bit
 due to the gray zone between amd64/x86 keyword and ABIs.
 
 
 And no, optional MULTILIB_COMPAT is a no-go. It's a weird breed of
 opt-in and opt-out which is just awful.
 
 
 
 2) USE flag names or ABI names?
 
 Next thing to decide would be: whether the restrict should specify USE
 flag names (like the eclass solution) or ABI names (like
 portage-multilib and profiles).
 
 The advantage of USE flags is that they are guaranteed to be unique
 and clear. As in, two arches won't ever have the same USE flag for ABI
 with the same name.
 
   MULTILIB_RESTRICT_ABIS=( abi_x86_x32 )
 
 The advantage of ABI names is that multilib-portage is aware of them.
 So, it's mostly about supporting a poor choice done without consulting
 other developers.
 
   MULTILIB_RESTRICT_ABIS=( x32 )
 
 The problem with that is that a new arch can define an ABI with exactly
 the same name (since all ABI variables are profile-local). In that
 case, the restriction will unexpectedly apply to that arch.
 
 
 By the way, maybe we should move the flag - ABI mapping from
 the eclass to some global location in profiles? That would make it
 possible to use the global flags from multilib-portage as well.
 
 What are your thoughts?
 

Once the eclass has per-ABI header and binaries support, i would see
multilib-portage as fallback option for packages/arches, which dont yet
have multilib support via eclass. So i am ok with the USE flag names.

-- 

Thomas Sachau
Gentoo Linux Developer



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog

2013-03-03 Thread Rich Freeman

On Sun, Mar 3, 2013 at 7:38 AM, Peter Stuge pe...@stuge.se wrote:

 To me it's obvious that he did it because it made something easier
 for him. By breaking the Gentoo rule he got something done.

Rules exist for a reason.  If we're bending them because we're
accomplishing the goal of the rules in a better way that makes sense.
If we're just breaking them because following them is inconvenient
then we're causing harm.

The purpose of the 30-day rule is so that stable is, well, stable.
Stable doesn't mean I think this should work.  Stable means that it
has been tested and found to work - a time delay is almost essential
to the definition of stability.

There is room for an exception if there is some serious problem in
stable and the risk of causing harm is low compared to the pain
already being felt.  Security bugs usually involve breaking the 30-day
rule, for example.  In these cases the spirit of the rule is contrary
to the letter of the rule, and we rightly violate the letter as a
result.

There is no harm in pointing out that a rule was broken.  If there is
a good reason it will be produced and everybody will nod, and if not,
well, then hopefully there will be an apology and we'll just move on.
Neither blacklisting nor banishment are the right first response to a
minor offense, but devs have been booted for consistently violating
rules like the 30 day rule, and I would expect mentors and recruiters
to ensure that new recruits understand and intend to follow this rule.
 Anybody who runs a stable system is better off for it.

Countless threads on -dev (mail or irc) amount to I'd like to violate
this rule for a good reason.  There is some debate, and we either do
it or not.  Rules aren't intended to prevent progress, but quality is
important and if a rule is standing in your way there might be some
side of the problem that you're not seeing.  It never hurts to ask
before breaking a rule.

Rich

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog

2013-03-03 Thread hasufell

On 03/03/2013 08:11 AM, Alec Warner wrote:
 
 There was a big ole' chat on #gentoo-dev regarding this. My
 understanding of the summary is that the nvidia-driver Gentoo team
 only supports kernels that nvidia themselves (upstream) support. The
 Kernels  3.4 are not supported by upstream, so they are also not
 supported in Gentoo. I believe the ebuild contains instructions on
 using user_patches to get these patches. The nvidia maintainers in
 Gentoo do not want to be responsible for those patches though; this is
 why they are not included (and why your commit was reverted.)
 
 I do not find their stance wholly unreasonable. They offered to point
 users at an overlay, if someone was willing to maintain the patches
 there (in lieu of user_patches.) The end result is that if users apply
 the patches, they will get an unsupported setup. There is a fear as
 well, that the patches may damage cards (since the patches are not
 supported by the vendor.)

What do we have useflags for in gentoo?

add a unsupported-kernels useflag, mask it, add a clear statement in
the masking reason and be done

Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs

On Sun, 03 Mar 2013 14:02:58 +0100
Thomas Sachau to...@gentoo.org wrote:
 
 Once the eclass has per-ABI header

I think this is needed.

 and binaries support,

but here, could you enlighten me on its use cases ? I can't imagine
why having multi binaries support would be useful.

Alexis.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog

On 3 March 2013 12:38, Peter Stuge pe...@stuge.se wrote:
 Markos Chandras wrote:
  I explain to you what happened

 getting stuff done is not an answer. I still don't understand why
 stable keywords had to be added directly. Do you understand why Mike
 did that or just playing smart here?

 To me it's obvious that he did it because it made something easier
 for him. By breaking the Gentoo rule he got something done.

I asked why he did it, and you keep telling me because he had to. When
you are in place
to give me a more detailed answer please do so otherwise I am asking
you to stop making noise
on the list.



 Instead of you giving me cryptic and smart answers, you could
 have explained to me why it was necessary and job done.

 I have no idea what exactly became easier for him, and what it is may
 be none of our business.

Maybe it is not your business, but I am reviewing commits from time to
time because:

a) I often see useful tricks in ebuild writing so it is a good
learning procedure and
b) because some people may did a bad commit so I would like to be
there and point them at it

In this case, I would like to know the reasoning behind that commit.
I am not the Gentoo police, just trying to understand the commits that
don't make sense to me. It this *that* hard for you to understand it?


 Again, I guess you have to make Mike go away now.


I never said that so please just stop it.


-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

[gentoo-dev] net-misc/omniORB up for grabs

After talking with Caster. Feel free to get it

Thanks


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

Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs

Alexis Ballier schrieb:
 On Sun, 03 Mar 2013 14:02:58 +0100
 Thomas Sachau to...@gentoo.org wrote:

 Once the eclass has per-ABI header
 
 I think this is needed.
 
 and binaries support,
 
 but here, could you enlighten me on its use cases ? I can't imagine
 why having multi binaries support would be useful.
 
 Alexis.
 


At least some binaries do have abi-specific output, which is used by
other applications. As a good example of this, have a look at qmake and
qmake based build systems.

-- 

Thomas Sachau
Gentoo Linux Developer



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Packages up for grabs

After talking with serkan the following packages are now up for grabs:
x11-libs/gtkhotkey
gnome-extra/file-browser-applet
app-mobilephone/ganyremote



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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog

2013-03-03 Thread Carlos Silva

On Sun, Mar 3, 2013 at 1:42 PM, hasufell hasuf...@gentoo.org wrote:

 What do we have useflags for in gentoo?

 add a unsupported-kernels useflag, mask it, add a clear statement in
 the masking reason and be done


Not a bad solution, still, I, as a user, don't think making the compilation
work with a specific kernel should be considered unsupported. How many
times modules stop working because the kernel changed something that
breakes compilation? And I'm not only talking  about closed source drivers,
even open source ones have this problem, but in fact, they are fixed
faster.

Does the gentoo community really need this kind of strictness? Don't think
so.

Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs

2013-03-03 Thread Chí-Thanh Christopher Nguyễn

Alexis Ballier schrieb:
 and binaries support,
 but here, could you enlighten me on its use cases ? I can't imagine
 why having multi binaries support would be useful.

One example is glxinfo from the mesa-progs package, it will display the
information for the ABI it is compiled with. So if you want to know
about the state of GLX/OpenGL acceleration for x86 applications, you
will need x86 glxinfo.


Best regards,
Chí-Thanh Christopher Nguyễn

[gentoo-dev] net-proxy herd is empty

As wschlich no longer has enough time for that packages, this herd is
now empty. If you want to help, please join the herd. If nobody joins, I
will proceed with dropping it and moving its packages maintainer-needed
letting everybody want the packages they prefer.

Thanks


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

Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs

On Sun, 03 Mar 2013 16:47:43 +0100
Thomas Sachau to...@gentoo.org wrote:

 Alexis Ballier schrieb:
  On Sun, 03 Mar 2013 14:02:58 +0100
  Thomas Sachau to...@gentoo.org wrote:
 
  Once the eclass has per-ABI header
  
  I think this is needed.
  
  and binaries support,
  
  but here, could you enlighten me on its use cases ? I can't imagine
  why having multi binaries support would be useful.
  
  Alexis.
  
 
 
 At least some binaries do have abi-specific output, which is used by
 other applications. As a good example of this, have a look at qmake
 and qmake based build systems.

hmm, qmake doesnt seem to be the perfect example: how do you handle
this?

- install qmake-${abi}
- ln -s qmake-${DEFAULT_ABI} qmake
- modify eqmake4 to call the right qmake when doing multilib?

this sounds hackish for a behavior that doesn't make much sense to me
(its an upstream problem here); the glxinfo example seems perfectly
valid though.

Alexis.

Re: [gentoo-dev] net-proxy herd is empty

2013-03-03 Thread Tom Wijsman

On Sun, 03 Mar 2013 17:00:57 +0100
Pacho Ramos pa...@gentoo.org wrote:

 As wschlich no longer has enough time for that packages, this herd is
 now empty. If you want to help, please join the herd. If nobody
 joins, I will proceed with dropping it and moving its packages
 maintainer-needed letting everybody want the packages they prefer.
 
 Thanks

Not joining until others join because I don't want to be the sole
herd member, but I do want to help out with occasional bumps and such
if there clearly is a case of lack of manpower.

I'm also interested in stepping up as a maintainer for
net-proxy/privoxy.


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: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog

2013-03-03 Thread Alec Warner

On Sun, Mar 3, 2013 at 7:49 AM, Carlos Silva r3...@r3pek.org wrote:
 On Sun, Mar 3, 2013 at 1:42 PM, hasufell hasuf...@gentoo.org wrote:

 What do we have useflags for in gentoo?

 add a unsupported-kernels useflag, mask it, add a clear statement in
 the masking reason and be done


 Not a bad solution, still, I, as a user, don't think making the compilation
 work with a specific kernel should be considered unsupported. How many
 times modules stop working because the kernel changed something that breakes
 compilation? And I'm not only talking  about closed source drivers, even
 open source ones have this problem, but in fact, they are fixed faster.

 Does the gentoo community really need this kind of strictness? Don't think
 so.


So I'm going to get a bit meta here, forgive me ;)

Currently the project more or less functions on herd and maintainer
'ownership.' Ownership of problems tends to be good in many cases. It
is clear who is responsible, we know who to contact to fix bugs and
ask questions of. This does lead to disagreements (such as this
thread.) Some developers want these patches and the package
maintainers disagree. In the current scheme, the package maintainer
always wins. This is the downside to ownership, ownership implies
control and responsibility. The package maintainers are against these
patches, they do not want to own them, and they do not want the
associated responsibility of users using them.

I don't even necessarily mind Samuli's commit (ask for forgiveness,
not permission), but I would mind if he put the patches back. The
package maintainer has spoken out about why they dislike the patches
and you should respect their opinion. The maintainers in this case
suggested an overlay, and they even offered point users to it.

This is the system we have; if you think it sucks (and it does,
sometimes) please propose something better.

-A

Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs

Alexis Ballier schrieb:
 On Sun, 03 Mar 2013 16:47:43 +0100
 Thomas Sachau to...@gentoo.org wrote:
 
 Alexis Ballier schrieb:
 On Sun, 03 Mar 2013 14:02:58 +0100
 Thomas Sachau to...@gentoo.org wrote:

 Once the eclass has per-ABI header

 I think this is needed.

 and binaries support,

 but here, could you enlighten me on its use cases ? I can't imagine
 why having multi binaries support would be useful.

 Alexis.



 At least some binaries do have abi-specific output, which is used by
 other applications. As a good example of this, have a look at qmake
 and qmake based build systems.
 
 hmm, qmake doesnt seem to be the perfect example: how do you handle
 this?
 
 - install qmake-${abi}

ok

 - ln -s qmake-${DEFAULT_ABI} qmake

Just the same as with headers:

You dont symlink the headers for the default ABI, but instead a wrapper
is placed, which does then call/include the real target, so in this
case, qmake is then a symlink to the abiwrapper, which does execute the
real abi-specific binary, depending on the current ABI.
We can of course place this abiwrapper in every place, where it is
needed instead of the symlink, but having one central and package
provided wrapper instead is easier to maintain and update.

 - modify eqmake4 to call the right qmake when doing multilib?

not needed at all (with multilib-portage), since when any package calls
qmake to get any abi-specific details, the abiwrapper executes the
binary, that matches the ABI and you get the right details for your ABI.

-- 

Thomas Sachau
Gentoo Linux Developer



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs

On Sun, 03 Mar 2013 17:27:50 +0100
Thomas Sachau to...@gentoo.org wrote:

 Alexis Ballier schrieb:
  On Sun, 03 Mar 2013 16:47:43 +0100
  Thomas Sachau to...@gentoo.org wrote:
  
  Alexis Ballier schrieb:
  On Sun, 03 Mar 2013 14:02:58 +0100
  Thomas Sachau to...@gentoo.org wrote:
 
  Once the eclass has per-ABI header
 
  I think this is needed.
 
  and binaries support,
 
  but here, could you enlighten me on its use cases ? I can't
  imagine why having multi binaries support would be useful.
 
  Alexis.
 
 
 
  At least some binaries do have abi-specific output, which is used
  by other applications. As a good example of this, have a look at
  qmake and qmake based build systems.
  
  hmm, qmake doesnt seem to be the perfect example: how do you handle
  this?
  
  - install qmake-${abi}
 
 ok
 
  - ln -s qmake-${DEFAULT_ABI} qmake
 
 Just the same as with headers:
 
 You dont symlink the headers for the default ABI, but instead a
 wrapper is placed, which does then call/include the real target, so
 in this case, qmake is then a symlink to the abiwrapper, which does
 execute the real abi-specific binary, depending on the current ABI.
 We can of course place this abiwrapper in every place, where it is
 needed instead of the symlink, but having one central and package
 provided wrapper instead is easier to maintain and update.
 
  - modify eqmake4 to call the right qmake when doing multilib?
 
 not needed at all (with multilib-portage), since when any package
 calls qmake to get any abi-specific details, the abiwrapper executes
 the binary, that matches the ABI and you get the right details for
 your ABI.
 

Indeed, nice idea. The wrapper can just call argv[0]-${ABI} or argv[0]
if ABI is unset or argv[0]-${ABI} does not exist.
Do you install this abiwrapper with multilib-portage? What would you
think about splitting it and adding such a package to the tree?

Alexis.

Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs

2013-03-03 Thread Michał Górny

On Sun, 03 Mar 2013 17:27:50 +0100
Thomas Sachau to...@gentoo.org wrote:

 Alexis Ballier schrieb:
  On Sun, 03 Mar 2013 16:47:43 +0100
  Thomas Sachau to...@gentoo.org wrote:
  
  Alexis Ballier schrieb:
  On Sun, 03 Mar 2013 14:02:58 +0100
  Thomas Sachau to...@gentoo.org wrote:
 
  Once the eclass has per-ABI header
 
  I think this is needed.
 
  and binaries support,
 
  but here, could you enlighten me on its use cases ? I can't imagine
  why having multi binaries support would be useful.
 
  Alexis.
 
 
 
  At least some binaries do have abi-specific output, which is used by
  other applications. As a good example of this, have a look at qmake
  and qmake based build systems.
  
  hmm, qmake doesnt seem to be the perfect example: how do you handle
  this?
  
  - install qmake-${abi}
 
 ok
 
  - ln -s qmake-${DEFAULT_ABI} qmake
 
 Just the same as with headers:
 
 You dont symlink the headers for the default ABI, but instead a wrapper
 is placed, which does then call/include the real target, so in this
 case, qmake is then a symlink to the abiwrapper, which does execute the
 real abi-specific binary, depending on the current ABI.
 We can of course place this abiwrapper in every place, where it is
 needed instead of the symlink, but having one central and package
 provided wrapper instead is easier to maintain and update.
 
  - modify eqmake4 to call the right qmake when doing multilib?
 
 not needed at all (with multilib-portage), since when any package calls
 qmake to get any abi-specific details, the abiwrapper executes the
 binary, that matches the ABI and you get the right details for your ABI.

What do we need that wrapper for? What does the wrapper do? Does it
just rely on custom 'ABI' variable? Or maybe should it try to detect
whether it was called by a 64- or 32-bit app? What for?

It's just a needless complexity, a big tool to handle a few corner
cases. Alexis just pointed out a perfectly good way of handling it.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Some packages up for grabs

2013-03-03 Thread Wolfram Schlich

Hey again!

Some of the packages I offered for grabs have been taken
a while ago, thanks everyone. Here are the remaining ones:

* Wolfram Schlich wschl...@gentoo.org [2012-12-01 11:02]:
 [...]
 Feel free to take care of the following packages that I used to
 maintain a while ago but don't anymore due to change of interest:
 
 - RAID controller utils:
 
 sys-block/afacli  (older Adaptec)
 sys-block/dellmgr (older Dell-branded LSI MegaRAID)
 [...]
 sys-block/lsiutil (LSI MegaRAID)

Dropped to maintainer-nee...@gentoo.org

 - Other packages:
 
 app-arch/afio
 app-misc/digitemp
 [...]
 media-gfx/dcraw
 net-analyzer/nmbscan
 net-analyzer/portbunny
 net-dns/fpdns
 [...]
 sys-block/spindown
 sys-fs/inotify-tools
 sys-fs/owfs

Dropped to maintainer-nee...@gentoo.org

Cheers,
Wolfram

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog

2013-03-03 Thread Ryan Hill

On Sun, 03 Mar 2013 15:42:56 +0100
hasufell hasuf...@gentoo.org wrote:

 What do we have useflags for in gentoo?

Not for conditional patching, that's for sure.

 add a unsupported-kernels useflag, mask it, add a clear statement in
 the masking reason and be done

If the description of the flag you're adding could be paraphrased to be
enable this or nothing works then you really shouldn't be allowed within 10
feet of any system with a tree checkout on it.  30 feet if you're also
suggesting it should be disabled by default.


-- 
gcc-porting
toolchain, wxwidgetslearn a language baby, it's that kind of place
@ gentoo.org   where low card is hunger and high card is taste


signature.asc
Description: PGP signature

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog

2013-03-03 Thread Ryan Hill

On Sat, 2 Mar 2013 23:11:44 -0800
Alec Warner anta...@gentoo.org wrote:

 I do not find their stance wholly unreasonable. They offered to point
 users at an overlay, if someone was willing to maintain the patches
 there (in lieu of user_patches.) The end result is that if users apply
 the patches, they will get an unsupported setup. There is a fear as
 well, that the patches may damage cards (since the patches are not
 supported by the vendor.)

We're talking about updating an include path here.  Some files moved.  I don't
think that justifies breaking stable. 


-- 
gcc-porting
toolchain, wxwidgetslearn a language baby, it's that kind of place
@ gentoo.org   where low card is hunger and high card is taste


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog

2013-03-03 Thread Carlos Silva

On Sun, Mar 3, 2013 at 4:39 PM, Ryan Hill dirtye...@gentoo.org wrote:

 On Sat, 2 Mar 2013 23:11:44 -0800
 Alec Warner anta...@gentoo.org wrote:

  I do not find their stance wholly unreasonable. They offered to point
  users at an overlay, if someone was willing to maintain the patches
  there (in lieu of user_patches.) The end result is that if users apply
  the patches, they will get an unsupported setup. There is a fear as
  well, that the patches may damage cards (since the patches are not
  supported by the vendor.)

 We're talking about updating an include path here.  Some files moved.  I
 don't
 think that justifies breaking stable.


Exactly my point. This a simple make-it-compile-without-any-new-stuff,
not add-this-cool-new-feature-to-the-package patch. There are differences
in them...

Again, it's just me, and i don't complain if the maintainer doesn't wan't
to accept the patch, i'm just expressing my opinion.

Re: [gentoo-dev] net-proxy herd is empty

2013-03-03 Thread Pavlos Ratis

On Sun, Mar 3, 2013 at 6:16 PM, Tom Wijsman tom...@gentoo.org wrote:
 On Sun, 03 Mar 2013 17:00:57 +0100
 Pacho Ramos pa...@gentoo.org wrote:

 As wschlich no longer has enough time for that packages, this herd is
 now empty. If you want to help, please join the herd. If nobody
 joins, I will proceed with dropping it and moving its packages
 maintainer-needed letting everybody want the packages they prefer.

 Thanks

 Not joining until others join because I don't want to be the sole
 herd member, but I do want to help out with occasional bumps and such
 if there clearly is a case of lack of manpower.

 I'm also interested in stepping up as a maintainer for
 net-proxy/privoxy.


 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

I am interested in joining the herd. Now we can be 2 members. :)

[gentoo-dev] proxy-maintainers herd as a backup herd for all the user-maintained packages

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

A number of packages in the tree are maintained by a Gentoo developer
and a user. As a result of which, we are unable to monitor these
packages in bugzilla. This is useful in case one of the maintainers
goes MIA so we can find an alternative maintainer for them. So I am
kindly asking you to add the proxy-maintainers herd as a backup herd
for the packages that you proxy-maintain. I will go ahead and do it
myself in two weeks if you don't want to bother fixing your metadata.
If you want your packages to be excluded please let me know. This is
mainly for tracking purposes and we don't intend to take over the
maintainership of your packages (unless you want us to).

- -- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQJ8BAEBCgBmBQJRM6X8XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw
OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88nwkP/2opVUCFBOE05djHu9mFVBWg
V95hiH8Twg2fZoFfBLohyt2UAN0ZbYWmTbTIzZsglAPzBSQIz1pFLp08ZEjxKXXF
iOuuTmLKLFy/QJisbmFOuTHXc7tqdPnBdbPQFb9+ntU42PINus6IbY2QXBDpZY/s
AEbUF2D0XjFGbHd63VrUMyzC4/4M8Fxn3e3OZ19dZHUVYZ3p/pUlwubVmkwb7Z45
YKEk5yxdYrGZuwKFtn4fK4/suPvqDqARZ5B4bBg3vgm2I8pUTTZqiZuKSMaobaTo
fbcuNZE99hOtXHzOgQmhLJSBrTy2gju2ygLrvJPIoREvHXfVC1CYxAm7FWXSyVsk
IfuvN0WXT0dCEzTqet/fYjpETe2ZOaFpY9sUyUHB9S9Ifv8G2zVQIdXw+nNol7Kq
6Vs6WbZiC9Hk+ycsE+bR07QgXl7bh/I4rAsnKJKv8J+Y2Tw05ADrSHNk0GrFfKs7
BFjkM8tZ/4vonaRjmEKAqPjiXnKKUa2ovPNvrWx8BDLcDsyltswSaPq9luZSvUPT
bDA2/ptHYoeNr+W7k95OdY1/p1MFcuImfGODDucX3vXyQLPOvqhwUK8ifPuQOaYJ
ij+rnczHQ4qtwa64aYSOSs2z/M6GZK+4cp3QCBMyt4BADBOskUNy+MisHEqzLvvB
DJuBD7BJAiPU4tYsBp1/
=xmSv
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog

2013-03-03 Thread Chí-Thanh Christopher Nguyễn

Ryan Hill schrieb:
 On Sun, 03 Mar 2013 15:42:56 +0100
 hasufell hasuf...@gentoo.org wrote:

 What do we have useflags for in gentoo?

 Not for conditional patching, that's for sure.

USE=vanilla already controls conditional patching for around two dozen
packages.

 add a unsupported-kernels useflag, mask it, add a clear statement in
 the masking reason and be done

 If the description of the flag you're adding could be paraphrased to be
 enable this or nothing works then you really shouldn't be allowed
within 10
 feet of any system with a tree checkout on it. 30 feet if you're also
 suggesting it should be disabled by default.

Not that I care about nvidia-drivers, but how about Increase kernel
compatibility at the cost of a supportable system.


Best regards,
Chí-Thanh Christopher Nguyễn

[gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers

2013-03-03 Thread Doug Goldstein

One of the reasons people volunteer in open source projects is to
scratch their personal itch. When that itch develops into a festering,
gangrenous limb it becomes time to amputate it. That is what I am
doing with my involvement in x11-drivers/nvidia-drivers. As a result
someone will need to work with spock and rej to figure out what
aspects they are able to maintain and then maintain the components
they aren't able to. For example, different hardware has different
series of drivers to support it.

-- 
Doug Goldstein

Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs

Alexis Ballier schrieb:
On Sun, 03 Mar 2013 17:27:50 +0100
Thomas Sachau to...@gentoo.org wrote:

Alexis Ballier schrieb:
On Sun, 03 Mar 2013 16:47:43 +0100
Thomas Sachau to...@gentoo.org wrote:

Alexis Ballier schrieb:
On Sun, 03 Mar 2013 14:02:58 +0100
Thomas Sachau to...@gentoo.org wrote:

Once the eclass has per-ABI header

I think this is needed.

and binaries support,

but here, could you enlighten me on its use cases ? I can't
imagine why having multi binaries support would be useful.

Alexis.

At least some binaries do have abi-specific output, which is used
by other applications. As a good example of this, have a look at
qmake and qmake based build systems.

hmm, qmake doesnt seem to be the perfect example: how do you handle
this?

- install qmake-${abi}

- ln -s qmake-${DEFAULT_ABI} qmake

Just the same as with headers:

You dont symlink the headers for the default ABI, but instead a
wrapper is placed, which does then call/include the real target, so
in this case, qmake is then a symlink to the abiwrapper, which does
execute the real abi-specific binary, depending on the current ABI.
We can of course place this abiwrapper in every place, where it is
needed instead of the symlink, but having one central and package
provided wrapper instead is easier to maintain and update.

- modify eqmake4 to call the right qmake when doing multilib?

not needed at all (with multilib-portage), since when any package
calls qmake to get any abi-specific details, the abiwrapper executes
the binary, that matches the ABI and you get the right details for
your ABI.

Indeed, nice idea. The wrapper can just call argv[0]-${ABI} or argv[0]
if ABI is unset or argv[0]-${ABI} does not exist.
Do you install this abiwrapper with multilib-portage? What would you
think about splitting it and adding such a package to the tree?

Alexis.

The wrapper is already in a seperate package [1], the currently active
and tested version (1.0) is in bash, also there is a (currently masked)
version 2.0 written by binki in C doing the same natively. So you even
have a choice in what to use. :-)

[1]:
http://git.overlays.gentoo.org/gitweb/?p=proj/multilib-portage.git;a=tree;f=sys-apps/abi-wrapper

Thomas Sachau
Gentoo Linux Developer

signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] net-proxy herd is empty

2013-03-03 Thread Tom Wijsman

On Sun, 3 Mar 2013 21:00:19 +0200
Pavlos Ratis daster...@gentoo.org wrote:

 I am interested in joining the herd. Now we can be 2 members. :)

Added us both to the net-proxy herd and mail alias.


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] net-proxy herd is empty