date:20121125

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/24/2012 03:30 PM, Theo Chatzimichos wrote:
 Hello,
 
 We currently have values like the following: RUBY_TARGETS=ruby19 
 PHP_TARGETS=php5-3 PYTHON_TARGETS=python2_7
 
 I find it confusing, and I would like to propose to keep the same
 style for all the above values. I personally prefer the ruby one. 
 Keep in mind that if the relevant teams decide to migrate to some
 other style, it needs an announcement and migration plan.
 

I don't find it confusing and I don't care, so I think it's useless
work to migrate to one or another.

There are far worse things to fix like the required_use messages
confusing users every day if you read #gentoo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQsfb/AAoJEFpvPKfnPDWzDUoH/29pWD/m5wbuVOhyDciPfP6i
sZ0OOT8JtlaysTnbSQrduGETYiZp29fTy7ZTOZkrYEuTZzfc3ozHeMm+aG1kvIjs
sWqzWVPFmyRcvO8srZvW3PnWWn2Dirrn4gPw64hUFmOvUR+PFoFSFVDfy/SrY7WG
jKaiN5m79KBj76Edd13tYTvAxTjSeSy4Ad0SH0IxcLhGPZQ8R39sGrYpPTLTAHMx
aEITq7FChQZqs/fdjBLkoOurYiDgTbbD1X+0+5E8pGXyb0/trJOkDpTyE5EPgfTa
W6IUKOj6obFGWPMDH71kFtv7l/u8ryxFIre9m+kSyh2/pC9awSTt0LMLv4oUtQg=
=p+nO
-END PGP SIGNATURE-

[gentoo-dev] fixing LICENSE issues without reporting bugs

The discussion came up in the thread
[gentoo-dev] open season on other-dev's packages -- policy change?

License issues seem trivial enough (at least regarding the functionality
of an ebuild) to be fixed without permission of the actual maintainer.

Even if the fix is wrong the ebuild remains intact.

If someone feels uncomfortable about this proposal we could limit this
permission to the license herd.

Less bugs, quicker fixes.

Re: [gentoo-dev] fixing LICENSE issues without reporting bugs

2012-11-25 Thread Ulrich Mueller

 On Sun, 25 Nov 2012, hasufell  wrote:

 License issues seem trivial enough (at least regarding the
 functionality of an ebuild) to be fixed without permission of the
 actual maintainer.

Certainly there are trivial license issues, but not all of them are.
See bugs 436452 and 441734 for trivial examples, and bugs 440938 and
12 for non-trivial ones. I think that it's better if bugs are
filed for the second category, so that the change will be traceable.
Also the maintainer should at least be informed in case the LICENSE
change would remove the package from the @FREE license group.

 Even if the fix is wrong the ebuild remains intact.

 If someone feels uncomfortable about this proposal we could limit
 this permission to the license herd.

 Less bugs, quicker fixes.

For the remaining trivial cases I'm fine with it either way. And
there's no reason to limit the permission to the licenses team.

Ulrich

Re: [gentoo-dev] fixing LICENSE issues without reporting bugs

2012-11-25 Thread Roy Bamford

On 2012.11.25 13:44, Ulrich Mueller wrote:
  On Sun, 25 Nov 2012, hasufell  wrote:
 
  License issues seem trivial enough (at least regarding the
  functionality of an ebuild) to be fixed without permission of the
  actual maintainer.
 
 Certainly there are trivial license issues, but not all of them are.
 See bugs 436452 and 441734 for trivial examples, and bugs 440938 and
 12 for non-trivial ones. I think that it's better if bugs are
 filed for the second category, so that the change will be traceable.
 Also the maintainer should at least be informed in case the LICENSE
 change would remove the package from the @FREE license group.
 
  Even if the fix is wrong the ebuild remains intact.
 
  If someone feels uncomfortable about this proposal we could limit
  this permission to the license herd.
 
  Less bugs, quicker fixes.
 
 For the remaining trivial cases I'm fine with it either way. And
 there's no reason to limit the permission to the licenses team.
 
 Ulrich
 
 

From the point of view of the licencor, the licence is just as 
important as the code, so there are no trivial licence issues.
As a trustee, I am unhappy with losing the traceability at all.
Other trustees may have different opinions.

What seems trivial today, may not be trivial tomorrow if a licencor 
gets upset.
   
-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpnkQh05fT1u.pgp
Description: PGP signature

Re: [gentoo-dev] proposal for consistency between {RUBY,PYTHON,PHP}_TARGETS

2012-11-25 Thread Peter Stuge

Ole Markus With wrote:
 Maybe I could change the currently masked php5-5 slot to php5_5 instead
 and then eventually phase our the hyphen based slots. This would mean
 inconsistency between the php slots for some time, but eventual
 consistency with Python, which I do see as a good thing.

I think that's a good idea. Go for it.


Duncan wrote:
 these changes will require end-user configuration changes.

I don't know if it's neccessary to make a change overnight. I think
the gradual approach is fine, even if it will take a bit of time to
reach the sky.


 I know a lot of former gentooers who already complain about both
 that, and about the need for constant attention to config changes

I would never update a package unless I actually wanted to update it.


//Peter

Re: [gentoo-dev] fixing LICENSE issues without reporting bugs

On Sun, Nov 25, 2012 at 9:30 AM, Roy Bamford neddyseag...@gentoo.org wrote:
 From the point of view of the licencor, the licence is just as
 important as the code, so there are no trivial licence issues.
 As a trustee, I am unhappy with losing the traceability at all.
 Other trustees may have different opinions.

Not this one.  License issues can vary in severity, and there may be
nuances that an outsider might not appreciate.

I think it is best to at least ping the maintainer before switching a
license.  If anybody spots a license issue that they believe to be
serious and they don't get a timely response from the maintainer, they
should escalate it.  I'd go a step further and request CCing the
trustees from the start on any issue that involves contact from the
copyright holder in any form.

Rich

Re: [gentoo-dev] fixing LICENSE issues without reporting bugs

2012-11-25 Thread Ulrich Mueller

 On Sun, 25 Nov 2012, Rich Freeman wrote:

 On Sun, Nov 25, 2012 at 9:30 AM, Roy Bamford neddyseag...@gentoo.org wrote:
 From the point of view of the licencor, the licence is just as
 important as the code, so there are no trivial licence issues.
 As a trustee, I am unhappy with losing the traceability at all.
 Other trustees may have different opinions.

But there _are_ trivial cases (e.g., most of the init script issues,
bug 425702) where a simple ChangeLog entry would be enough for
traceability.

 Not this one.  License issues can vary in severity, and there may be
 nuances that an outsider might not appreciate.

 I think it is best to at least ping the maintainer before switching a
 license.  If anybody spots a license issue that they believe to be
 serious and they don't get a timely response from the maintainer, they
 should escalate it.  I'd go a step further and request CCing the
 trustees from the start on any issue that involves contact from the
 copyright holder in any form.

This can certainly be done. Be prepared for some bug spam, though.

Ulrich

Re: [gentoo-dev] fixing LICENSE issues without reporting bugs

On Sun, Nov 25, 2012 at 10:04 AM, Ulrich Mueller u...@gentoo.org wrote:

 But there _are_ trivial cases (e.g., most of the init script issues,
 bug 425702) where a simple ChangeLog entry would be enough for
 traceability.

I think something like that is best announced first, and then done if
there is no issue.  I have no issues with just moving forward with
that one without maintainer involvement.  Perhaps first just post a
list of packages that plan to be touched in the announcement.

 I think it is best to at least ping the maintainer before switching a
 license.  If anybody spots a license issue that they believe to be
 serious and they don't get a timely response from the maintainer, they
 should escalate it.  I'd go a step further and request CCing the
 trustees from the start on any issue that involves contact from the
 copyright holder in any form.

 This can certainly be done. Be prepared for some bug spam, though.

The key words are serious or contact from the copyright holder.
Bugs in these categories can't just sit around until a maintainer
comes back from vacation - if we are notified that somebody believes
we are possibly infringing copyright we need to take rapid action.  I
don't think that necessitates commit first and ask questions later,
but it does need to start getting looked at by human beings that day.

Also, my intent isn't to disenfranchise the licenses team.  The
Foundation is clearly accountable here, but insofar as the licenses
team can stay on top of serious issues I would expect the Trustees to
let them do their job.  I just want the message to be that at the end
of the day nobody should be able to argue that we didn't take what
they believed to be a serious licensing concern seriously.

Rich

Re: [gentoo-dev] fixing LICENSE issues without reporting bugs

On Sun, Nov 25, 2012 at 10:20 AM, Rich Freeman ri...@gentoo.org wrote:
 The key words are serious or contact from the copyright holder.

Sorry - revise that a little:
1.  Serious and they don't get a timely response from the maintainer
(or licenses@g.o).
or
2.  Contact from the copyright holder.

The intent isn't to make anybody wait for permission to fix licensing
issues, but rather to get the maintainer involved so that we make the
best decision possible, while ensuring that we aren't subject to legal
risk or unnecessarily hard feelings if a maintainer isn't available
for serious issues.

The Trustees don't need to be intimately involved in every issue, but
everybody does need to know that we're around if needed.  If we're
actually contacted by a copyright holder I suggested copying us since
I think that raises the bar legally - whether the note comes from a
lawyer or not we're essentially on notice and a timely response would
be expected by a court.

Rich

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/25/2012 02:01 AM, Patrick Lauer wrote:
 On 11/23/12 22:32, Thomas Sachau wrote:
 Ian Stakenvicius schrieb:
 On 22/11/12 11:22 PM, Robin H. Johnson wrote:
 On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz wrote:
 On 11:11 Sun 18 Nov , Robin H. Johnson wrote:
 Here's a list of every package where I'm a maintainer and there
 is no herd listed (but their might be other maintainers):
 I didn't say I was dropping any of the packages, merely making an 
 explicit list of packages I maintain, that other developers are
 welcome to touch - if they want to take them over explicitly, that
 would be great too.


 ..  For certain things, I think it would be very beneficial for this
 to be true (other dev's welcome to touch) across the tree.  Maybe if
 there is enough general support for it, we should change our default
 of never touch a maintainer's package without permission of the
 maintainer/herd, to OK to touch unless package metadata explicitly
 requests not to ...?  And we can put a tag in the metadata to
 indicate this (or even to indicate what other dev's can and can't
 touch -- ie, can touch *DEPEND, can bump EAPI, cannot add features,
 cannot bump)?

 Thoughts?




 What certain things do you have in mind? In wich situation do you see a
 simple May i touch the package?/ok for this patch? as too much to do
 before touching a package?

 To me it's random noise, if I'm in the package metadata just do it. No
 need to distract me :)

I completely agree.  There is a lot of territorialism that is
*completely* unwarranted.  If you see an issue with one of my packages
and want to fix it, please, be my guest. Especially if it had a bug on
bugzie and you close that bug.  I get an email when my packages are
touched, if I don't like your change I'll tell you why and then fix it.
 If you horribly break my package, you may hear about it, but you
certainly won't get yelled at for fixing my bugs or bumping a package.

Thanks,
Zero
 
 And there's tons of packages that have a maintainer in metadata and
 bugs just go into nirvana (like apache)...
 
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQsjykAAoJEKXdFCfdEflK0kUQAIB42lvd+oBP9xC9n9krkyzA
pIdQw/npCZtfQ4ZRXjkrhWf8uP9RkwB04qmFRO/DrxFlMu5QJ+wGPeu8zqRCJBri
GWqMATtZdvxHGeyKoAc/jJjp9+OHQ+izR7sGGo26uttj5QcA51e8e+568rw1xXk4
FQqQEOP9WXL8z8NOOo8ybv3SBqSg/+yHl05aInLhutKQAAtdOPy60nblGPMEyVIJ
deoMFUU5PsJRaAsHL30iBlclFpgn6UK8bdxTfMiXvEECUrAj+Hx6vSIh8cMPCdLq
SHT6Dcs8JkhKGEMX0v3CBzZ4yU/y36cSwNMah9eSFVnfW/R+7Mpt9Q3lfElwOSkl
OAtDqwEiyTgTG/ucOkFb+UBaAOpdlRsC0vbck5RDQaF3AWERpBx9AZ/qVjRg39jt
Yn7iads9FUAtrQ5bgMxHPkDlzNF50R99Ud41rJ1vZwl0JdrAgem5Pt2cO6TPEeZ8
6SeyVYQdRpqO3fMi6ijYTZEPiIX+EUJ8RkunUwgMHAhcn2IeAtkbbY5a3+1V2wpm
lIP5di6TujmlX7x9zy6UI2ItSnvlwX/rq2XkPOyo4j+wyyQJN4VD2QT4wERuDADK
ICJA/yke8tmsVo3Uxjtv8Yqbuug/AvD9blxlLpEPcuY5XKZOsxzzQFeRG7u5S+aZ
16yQHoOjDNFN9882Ggy5
=D8vW
-END PGP SIGNATURE-

Re: [gentoo-dev] fixing LICENSE issues without reporting bugs

2012-11-25 Thread Roy Bamford

On 2012.11.25 14:42, Rich Freeman wrote:
 On Sun, Nov 25, 2012 at 9:30 AM, Roy Bamford 
 neddyseag...@gentoo.org
 wrote:
  From the point of view of the licencor, the licence is just as
  important as the code, so there are no trivial licence issues.
  As a trustee, I am unhappy with losing the traceability at all.
  Other trustees may have different opinions.
 
 Not this one.  License issues can vary in severity, and there may be
 nuances that an outsider might not appreciate.
 
[snip]
 
 Rich
 

 
Rich,

That's my point - something serious may slip by without a bug.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpDPB0T8VgC0.pgp
Description: PGP signature

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

On Sun, Nov 25, 2012 at 10:43 AM, Rick Zero_Chaos Farina
zeroch...@gentoo.org wrote:
  If you horribly break my package, you may hear about it, but you
 certainly won't get yelled at for fixing my bugs or bumping a package.

While I think there is a balance to be found, keep in mind that you as
the developer aren't the only person impacted if somebody breaks a
package you maintain.  Perhaps your users would prefer that people
with less experience with the package not fiddle with it.

If a package has a responsive maintainer, then pinging them isn't
really much of a hurdle.  If the package doesn't have a responsive
maintainer, then perhaps that should be fixed.

I'm not saying that there shouldn't be some way for maintainers to
indicate when they're willing to allow others to touch packages
without asking.  I'm just saying that this isn't purely a matter of
maintainer preference, or territorialism.

Rich

[gentoo-dev] New eclass cuda.eclass

2012-11-25 Thread Justin

Hi,

I would like to introduce a new eclass for packages using the nvidia
cuda compiler suite. Currently the eclass simply sanitize the NVCCFLAGS.
May be extended in the future.

Two problems come up with using nvcc:

* Each version only supports a limited number of gcc versions. Therefore
we need to pass the path to a supported gcc bindir

* nvcc calls CXX but doesn't pass CXXFLAGS on.


justin
# Copyright 1999-20012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

inherit toolchain-funcs versionator

# @ECLASS: cuda.eclass
# @MAINTAINER:
# Justin Lecher j...@gentoo.org
# @BLURB: Common functions for cuda packages
# @DESCRIPTION:
# This eclass contains functions to be used with cuda package. Currently it is
# setting and/or sanitizing NVCCFLAGS, the compiler flags for nvcc. This is
# automatically done and exported in src_prepare() or manually by calling
# cuda_sanatize.
#
# Common usage:
#
# inherit cuda

# @ECLASS-VARIABLE: NVCCFLAGS
# DESCRIPTION:
# nvcc compiler flags (see nvcc --help), which should be used like
# CFLAGS for c compiler
: ${NVCCFLAGS:=-O2}

# @ECLASS-VARIABLE: CUDA_VERBOSE
# DESCRIPTION:
# Being verbose during compilation to see underlying commands
: ${CUDA_VERBOSE:=true}

[[ ${CUDA_VERBOSE} == true ]]  NVCCFLAGS+= -v

# @ECLASS-FUNCTION: cuda_gccdir
# @DESCRIPTION:
# Helper for determination of the latest gcc bindir supported by
# then current nvidia cuda toolkit.
#
# Calling plain it returns simply the path, but you probably want to add \-f\
# to get the full flag to add to nvcc call.
#
# Example:
#
# cuda_gccdir -f
# - --compiler-bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3
cuda_gccdir() {
local _gcc_bindir _ver _args= _flag _ret

# Currently we only support the gnu compiler suite
if [[ $(tc-getCXX) != *g++* ]]; then
ewarn Currently we only support the gnu compiler suite
return 2
fi

while [ $1 ]; do
case $1 in
-f)
_flag=--compiler-bindir=
;;
*)
;;
esac
shift
done

if [[ ! $(type -P cuda-config) ]]; then
eerror Could not execute cuda-config
eerror Make sure =dev-util/nvidia-cuda-toolkit-4.2.9-r1 is 
installed
die cuda-config not found
else
_args=$(version_sort $(cuda-config -s))
if [[ ! -n ${_args} ]]; then
die Could not determine supported gcc versions from 
cuda-config
fi
fi

for _ver in ${_args}; do
  has_version sys-devel/gcc:${_ver}  \
 _gcc_bindir=$(ls -d ${EPREFIX}/usr/*pc-linux-gnu/gcc-bin/${_ver}* | 
tail -n 1)
   done

   if [[ -n ${_gcc_bindir} ]]; then
if [[ -n ${_flag} ]]; then
_ret=${_flag}\\\${_gcc_bindir}\\\
else
  _ret=${_gcc_bindir}
fi
echo ${_ret}
return 0
else
eerror Only gcc version(s) ${_args} are supported,
eerror of which none is installed
die Only gcc version(s) ${_args} are supported
return 1
   fi
}

# @ECLASS-FUNCTION: cuda_sanitize
# @DESCRIPTION:
# Correct NVCCFLAGS by adding the necessary reference to gcc bindir and
# passing CXXFLAGS to underlying compiler without disturbing nvcc.
cuda_sanitize() {
# Tell nvcc where to find a compatible compiler
NVCCFLAGS+= $(cuda_gccdir -f)

# Tell nvcc which flags should be used for underlying C compiler
NVCCFLAGS+= --compiler-options=\${CXXFLAGS}\

export NVCCFLAGS
}

# @ECLASS-FUNCTION: cuda_pkg_setup
# @DESCRIPTION:
# Sanitise and export NVCCFLAGS by default in pkg_setup
cuda_pkg_setup() {
cuda_sanitize
}

EXPORT_FUNCTIONS pkg_setup
case ${EAPI:-0} in
   0|1|2|3|4|5) ;;
   *) die EAPI=${EAPI} is not supported ;;
esac


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/25/2012 10:51 AM, Rich Freeman wrote:
 On Sun, Nov 25, 2012 at 10:43 AM, Rick Zero_Chaos Farina
 zeroch...@gentoo.org wrote:
  If you horribly break my package, you may hear about it, but you
 certainly won't get yelled at for fixing my bugs or bumping a package.
 
 While I think there is a balance to be found, keep in mind that you as
 the developer aren't the only person impacted if somebody breaks a
 package you maintain.  Perhaps your users would prefer that people
 with less experience with the package not fiddle with it.
The developer fiddling with it needs to be confident they know what they
are doing (or at least have discussed it with more experienced
developers) before they fiddle with my packages.  My open invitation
for help should not be mistaken for an open invitation to experiment
with my packages.
 
 If a package has a responsive maintainer, then pinging them isn't
 really much of a hurdle.  If the package doesn't have a responsive
 maintainer, then perhaps that should be fixed.
The problem is what of people like me, some weeks I'm very responsive
(seconds to minutes) while other times I'm away from a computer for the
entire week with no warning.  I don't want people waiting to fix
something easy because they are being polite to me.  As you said, what
of my users? Do they feel it's good to wait a week (something I hear
all the time) for a simple fix simply because no one could reach me?  I
think not.
 
 I'm not saying that there shouldn't be some way for maintainers to
 indicate when they're willing to allow others to touch packages
 without asking.  I'm just saying that this isn't purely a matter of
 maintainer preference, or territorialism.

There shouldn't need to be a way for maintainers to indicate they are
willing to allow others to touch packages without asking, in my opinion
this should be the norm.

Again, no one should be randomly experimenting with someone else's
packages without asking, but fixes for obvious or even non-obvious
issues should be WELCOMED by all devs.  If you have a bug on bugzie that
is more than a week old and it affects me, you can bet I will fix it and
the notification you get will be the one from me closing your bug.  If
you have an issue with that maybe you should fix your own bugs.

When I say things like that I've had other devs threaten to find and
file bugs in my packages and then fix those bugs without asking me.
Really? Pretty please! If you see something I've missed you are welcome
to 1.) file a bug 2.) fix the bug if I'm not (nearly) immediately
responsive to assist.  I think this practice (overall) will improve
Gentoo for our users, and at the end of the day that's the only thing
that matters, not my ego.

Thanks,
Zero

PS If you need an explicit you are permitted to touch my packages
then here it is, signed with my gpg key and everything. Find my bugs,
fix my bugs, try really hard not to break things. Thanks for your help.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQslukAAoJEKXdFCfdEflKo/EQAKD4SNghLvMrEiNnEztnKbFu
pKCcSMReTlsnXbFiO4itrI9KqgwdKCh4kGLfza1pSU6OEkVWM9H0vC1N/E0drFpL
at2MYEQF8qW4xKebDV0NCzmTDxjvDtx5/XQVSmp53Xi4XWb0FWd2X2mn1I+frm/i
uHYlsUKwF6852/605k2+h3Z++svc4UBR7V63XNY0wsgOYsJlmrFg1fQxLCCgcGUS
qFhgMT+bgYUh5gceJwCtHomHdxN/D+In1ILZWwHwWalyNSg/nDN7sZrGde+5dSZ5
9MkBL/NqxaSwTsYUX0xly0/52QDVrNVEMJBN8rxcMT83Cw/w7yoNoBaa/nEmtlej
/UK9mOYE/+fNNWVOERiOv4t3YTvdq6B5kP+xAeG+P3jEq54U43mK/fEAH1chPRQG
j4dMuSWAGuMgiAzbdVwfK2OawB1z321V8JzsUHb7P91javqjlP1GHPWAE95+PMZn
6mEAGXrRGmUpyC/ihZnsjhMdg1n8SLf6V1HIMvGxXEbiY22vFf7PcYP7bkWvSOyP
9EiKLB3d1Cu0lfo75telmrCBRBndrziD+UAe9C0fSjizxGK2tsE+kivZZ9yf+vS+
BrtGNtRiH9Je2ugakgpjgFrVjbAPmqUQqGshWuEqBQOHi5HzTE/YcO63w0wjHJPx
Y8IrzQvqPcUKp1t28ofN
=ZtW0
-END PGP SIGNATURE-

Re: [gentoo-dev] New eclass cuda.eclass

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/25/2012 11:47 AM, Justin wrote:
 Hi,
 
 I would like to introduce a new eclass for packages using the nvidia
 cuda compiler suite. Currently the eclass simply sanitize the NVCCFLAGS.
 May be extended in the future.
 
 Two problems come up with using nvcc:
 
 * Each version only supports a limited number of gcc versions. Therefore
 we need to pass the path to a supported gcc bindir
 
 * nvcc calls CXX but doesn't pass CXXFLAGS on.
 
This whole idea seems great but I see two issues.  Issue 1.) I'm stupid
and don't really understand all the intricacy of the toolchain stuff and
2.) you didn't include an example ebuild.

Fortunately issue 1 can (at least functionally) be solved by providing a
solution for issue 2.  If you need an ebuild to cuda.eclassify then I am
happy to provide (or feel free to use a before and after of anything you
have available).

https://code.google.com/p/pentoo/source/browse/portage/trunk/app-crypt/cryptohaze-combined/cryptohaze-combined-.ebuild

Thanks!
Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQslyDAAoJEKXdFCfdEflKiKIQAJUGuKxqRY/ruCcSC98PWkOq
NsZr/C5YbZRfJlFlcb5LnA2qJJAxO04bun0zi6hbZWsMGLBI54qha/XGL9M0J+rm
qIubv8xFRVXfmSRdQMYSAYnA5xrLJVAu/H7jpq8stOFdP7COuXKjwknOhccap6yF
g8tMm5vClH7y+hLIMYn8xQ2ZIDO5cGTdFFNLIDOHk/el/ija+I+dR7BkMVeZ0tQc
CgbiUyBdgz1Ijc2yr6x5vc+8QGWvmGZMNslgnrlMpICyUY25xPAdrySNcVHHIAoA
4zBqmO4VIaWuzKOcUZEkSdtJHtyQPbmTVMwVfuf8gRm2wec1rsfkWqCORQ2SYVEk
aDcyZQFzb0D+vBc9Ic62+ejGe12GU++KZ3ivairT82Vls46Awkajepj0bILnC3jO
6shNvYLJTI38UEKMFWrTNMkeQgkOUZwftHylHF6AAtUTi4htMXdar9J9PV/uPQDJ
Z4VpElKO9OB87N7eFHDeB3A3q8G++N1WHOC14/z2pTKUEyr9NoivBYOMo5RxBLtD
mT8CbUe8NkVzcWJRoKu2EKg2i8fD7lpjZtw2/s8ADxtnyGZ4jZq73aOeY6hWgq4y
CFigbKYQtorV30GeTks9Vgs9tbbxVjXupaQ/TgaWEOUYA7I5IfQIyfqBzfFwHMPm
Uw6Kkmp5ihx0fH9gR8BH
=/idk
-END PGP SIGNATURE-

Re: [gentoo-dev] New eclass cuda.eclass

2012-11-25 Thread Justin

On 25.11.2012 18:59, Rick Zero_Chaos Farina wrote:
On 11/25/2012 11:47 AM, Justin wrote:
Hi,

I would like to introduce a new eclass for packages using the nvidia
cuda compiler suite. Currently the eclass simply sanitize the NVCCFLAGS.
May be extended in the future.

Two problems come up with using nvcc:

* Each version only supports a limited number of gcc versions. Therefore
we need to pass the path to a supported gcc bindir

* nvcc calls CXX but doesn't pass CXXFLAGS on.

This whole idea seems great but I see two issues. Issue 1.) I'm stupid
and don't really understand all the intricacy of the toolchain stuff and
2.) you didn't include an example ebuild.

Fortunately issue 1 can (at least functionally) be solved by providing a
solution for issue 2. If you need an ebuild to cuda.eclassify then I am
happy to provide (or feel free to use a before and after of anything you
have available).

https://code.google.com/p/pentoo/source/browse/portage/trunk/app-crypt/cryptohaze-combined/cryptohaze-combined-.ebuild

Thanks!
Zero

1)
The build fails if you are using a compiler newer then the supported ones.

In file included from /opt/cuda/include/cuda_runtime.h:59:0,
from command-line:0:
/opt/cuda/include/host_config.h:82:2: error: #error -- unsupported GNU
version! gcc 4.7 and up are not supported!
make[1]: *** [obj/x86_64/release/segmentationTree.cu_13.o] Error 1

or similar. Solution, tell nvcc where to find a compatible compiler.

2)
The underlying call of c compiler doesn't respect CXXFLAGS, therefore we
need to tell nvcc what to use. Otherwise only the plain NVCCFLAGS are used.

How to fix your package, depends on the buildsystem and where and how
they are calling the nvcc. Normally you need to sed it in.

Here as an example the nvidia-cuda-sdk version bump:

https://github.com/gentoo-science/sci/blob/cuda/dev-util/nvidia-cuda-sdk/nvidia-cuda-sdk-5.0.35.ebuild

justin

signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New eclass cuda.eclass

On 11/25/2012 02:14 PM, Justin wrote:
On 25.11.2012 18:59, Rick Zero_Chaos Farina wrote:
On 11/25/2012 11:47 AM, Justin wrote:
Hi,

I would like to introduce a new eclass for packages using the nvidia
cuda compiler suite. Currently the eclass simply sanitize the NVCCFLAGS.
May be extended in the future.

Two problems come up with using nvcc:

* Each version only supports a limited number of gcc versions. Therefore
we need to pass the path to a supported gcc bindir

* nvcc calls CXX but doesn't pass CXXFLAGS on.

This whole idea seems great but I see two issues. Issue 1.) I'm stupid
and don't really understand all the intricacy of the toolchain stuff and
2.) you didn't include an example ebuild.

https://code.google.com/p/pentoo/source/browse/portage/trunk/app-crypt/cryptohaze-combined/cryptohaze-combined-.ebuild

Thanks!
Zero

1)
The build fails if you are using a compiler newer then the supported ones.

or similar. Solution, tell nvcc where to find a compatible compiler.

I can see this improvement right away, love it.

2)
The underlying call of c compiler doesn't respect CXXFLAGS, therefore we
need to tell nvcc what to use. Otherwise only the plain NVCCFLAGS are used.

How to fix your package, depends on the buildsystem and where and how
they are calling the nvcc. Normally you need to sed it in.

Here as an example the nvidia-cuda-sdk version bump:

https://github.com/gentoo-science/sci/blob/cuda/dev-util/nvidia-cuda-sdk/nvidia-cuda-sdk-5.0.35.ebuild

I mostly get this, seems like a good thing.

All in all, definitely ACK. I like it.

Thanks,
Zero

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

On Sun, Nov 25, 2012 at 12:55 PM, Rick Zero_Chaos Farina
zeroch...@gentoo.org wrote:
 If you have a bug on bugzie that
 is more than a week old and it affects me, you can bet I will fix it and
 the notification you get will be the one from me closing your bug.  If
 you have an issue with that maybe you should fix your own bugs.

If you want to co-maintain a package, then ping the current maintainer
and add yourself to the maintainer list.  You can then stay in touch
with them and coordinate plans for keeping the package working.

Suppose that developer has the fix standing by, but is working on
something else and wants to fix both issues at once to cut down on
revbumps?  Maybe they have a few week's worth handy and were waiting
for the right moment.

The fact is that the behavior you are bragging about is in violation
of policy.  If you don't like the policy by all means chime in and
discuss it, or ask the council to take it up.

This isn't about being territorial.  If you want to help co-maintain a
package I maintain you're welcome to do so.  However, this is a
long-term commitment.  Otherwise, send me an email before you go
messing with things.  If you're doing tree-wide work then coordinate
it with the appropriate project lead and make announcements on
-dev-announce as needed.  Nobody wants to stand in the way of getting
bugs fixed - there is just a way to do it so that you don't drive
everybody crazy.

Rich

[gentoo-dev] net-irc/xchat

2012-11-25 Thread Lars Wendler

Hey list,

I'm planning to lastrite net-irc/xchat in the next couple of weeks.
Unfortunately my hope that upstream development would be resumed didn't come 
true. As the code becomes more and more outdated, open unfixed security bugs 
are present[1][2] and at some point in the future =x11-libs/gtk+-2* will 
vanish from the tree I don't see any other option than removing xchat from the 
tree.
I don't see this as a big drama as we already have a drop-in replacement in 
form of the net-irc/hexchat fork.
I checked this today and all people have to do is emerge hexchat and then copy 
over the xchat config:
  mkdir ${HOME}/.config ; cp -a ${HOME}/.xchat2 ${HOME}/.config/hexchat

I'd like to see your opinion on this matter as long as you have one you'd like 
to share with me ;)
Furthermore I would shift my attention from the xchat package to hexchat 
seeing that it currently gets proxy maintained. If there's no objection I'd 
like to become the new contact of the person currently maintaining the package 
in portage.

I also planned to release a news through the portage news system as soon as I 
lastrite xchat so people know how to move over to hexchat. As I never did this 
before I'd like to have some help concerning this matter. Is there some 
documentation about portage news?

Regards


[1] https://bugs.gentoo.org/394657
[2] https://bugs.gentoo.org/257006
-- 
Lars Wendler (Polynomial-C)
Gentoo package maintainer and bug-wrangler

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

Re: [gentoo-dev] net-irc/xchat

2012-11-25 Thread Zac Medico

On 11/25/2012 12:27 PM, Lars Wendler wrote:
 I also planned to release a news through the portage news system as soon as I 
 lastrite xchat so people know how to move over to hexchat. As I never did 
 this 
 before I'd like to have some help concerning this matter. Is there some 
 documentation about portage news?

There's a nice little set of instructions here:

  http://gentoo-pr.org/node/16

The news repository is in git these days:

  http://sources.gentoo.org/gitweb/?p=proj/gentoo-news.git;a=summary
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-office/lyx: lyx-2.0.5.ebuild ChangeLog

2012-11-25 Thread Alexis Ballier

On Sun, 25 Nov 2012 14:55:06 +0800
Patrick Lauer patr...@gentoo.org wrote:

 On 11/23/12 21:17, Alexis Ballier wrote:
  On Fri, 23 Nov 2012 12:45:56 +0800
  Patrick Lauer patr...@gentoo.org wrote:
  
  On 11/20/12 21:57, Alexis Ballier wrote:
  On Fri, 16 Nov 2012 09:10:51 + (UTC)
  Patrick Lauer (patrick) patr...@gentoo.org wrote:
 
  patrick 12/11/16 09:10:51
 
Modified: ChangeLog
Added:lyx-2.0.5.ebuild
Log:
Bump

 
 
 
  While the bump was fine, please read the damn metadata.xml when
  you touch a package you're not used to. Pavel has been doing a
  very good job in (proxy) maintaining lyx since years and you do
  not seem to have contacted him before doing the bump, which is a
  bit disrespectful for him IMHO.
 
  I disagree. A fix is a fix, a bump is a bump, no ego involved.
  
  And respect is respect. It's not because you woke up someday in a
  special mood that a 4+ years perfectly working workflow will
  change...
  
 
  If you want to help in having things done quicker because I'm not
  always responsive enough, then please do it correctly and ask
  Pavel to CC you when he sends me instructions for lyx.
  I dislike this territorialism. Why add a single point of failure to
  package maintenance? (What if you or Pavel disappear for any
  reason?)
  
  Ask those who invented maintainers. Take your point to the council.
  So far these are the rules, follow them or leave it.
  
  As for the single point of failure, Pavel being part of upstream
  sends me the ebuilds _before_ the actual release. That is not what
  I call a failure. The proposal to also be a proxy still stands, but
  if you continue with this provocative behavior I'm not sure I want
  to work with you...
  
  A.
  
 
 provocative
 
 Aaaargh.
 
 With that kind of agression from *your* side I might just ignore your
 input because you're really annoying me.

Please stop being childish, thanks.

 As for packages, all my packages are Do what you want, with an
 optional feel free to notify me if you change something...

Good for you. Please keep in mind that you're not alone in the world
and that others may have a different workflow.

A.

Re: [gentoo-dev] net-irc/xchat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/25/2012 09:27 PM, Lars Wendler wrote:
 Hey list,
 
 I'm planning to lastrite net-irc/xchat in the next couple of
 weeks. Unfortunately my hope that upstream development would be
 resumed didn't come true. As the code becomes more and more
 outdated, open unfixed security bugs are present[1][2] and at some
 point in the future =x11-libs/gtk+-2* will vanish from the tree I
 don't see any other option than removing xchat from the tree. I
 don't see this as a big drama as we already have a drop-in
 replacement in form of the net-irc/hexchat fork. I checked this
 today and all people have to do is emerge hexchat and then copy 
 over the xchat config: mkdir ${HOME}/.config ; cp -a
 ${HOME}/.xchat2 ${HOME}/.config/hexchat
 
 I'd like to see your opinion on this matter as long as you have one
 you'd like to share with me ;) Furthermore I would shift my
 attention from the xchat package to hexchat seeing that it
 currently gets proxy maintained. If there's no objection I'd like
 to become the new contact of the person currently maintaining the
 package in portage.
 
 I also planned to release a news through the portage news system as
 soon as I lastrite xchat so people know how to move over to
 hexchat. As I never did this before I'd like to have some help
 concerning this matter. Is there some documentation about portage
 news?
 
 Regards
 
 
 [1] https://bugs.gentoo.org/394657 [2]
 https://bugs.gentoo.org/257006

That's a pity. I was just about to step forward to rescue
net-irc/xchat-xsys from treecleaning.

Do xchat plugins work in hexchat?

Maybe we could just hardmask it. I see some ebuilds in the tree being
hardmasked due to security bugs, but not removed which is ok to me.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQsoeGAAoJEFpvPKfnPDWzkk0H/3GWd1Onq+xZXIaSs7InDooW
1GHhpVg4kJm/rYAH3qeO3USEhHaE9ul+EzdE+F6T9koEbWWrTZ9mLeDjrmmuig3i
aJc9wymm3JUCUXVe+m5aCWN/rpxvuaey4LBQnjUfdb1njUmIljnhx8PzEibyCrAc
k8sLGV0c6/e+PibDr6Exca7p/9yCgiCAfifcTI9XsSZGy8E6tBgV2wfaNN3K/XsA
vB9zBVQ6d3BXleExTQ03VL+MOlYf4Y7Zn5jafu5bouEcplXqrbWnbdtDPvcb/xjT
LdwelXOxwVp/U6ELftBUtxF47c68vnHvmVDa6N9Zz4PRbvpqiq9pqYXaGZHN3+o=
=LfSU
-END PGP SIGNATURE-

Re: [gentoo-dev] net-irc/xchat

2012-11-25 Thread Lars Wendler

Am Sonntag 25 November 2012, 22:03:03 schrieb hasufell:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 11/25/2012 09:27 PM, Lars Wendler wrote:
  Hey list,
  
  I'm planning to lastrite net-irc/xchat in the next couple of
  weeks. Unfortunately my hope that upstream development would be
  resumed didn't come true. As the code becomes more and more
  outdated, open unfixed security bugs are present[1][2] and at some
  point in the future =x11-libs/gtk+-2* will vanish from the tree I
  don't see any other option than removing xchat from the tree. I
  don't see this as a big drama as we already have a drop-in
  replacement in form of the net-irc/hexchat fork. I checked this
  today and all people have to do is emerge hexchat and then copy
  over the xchat config: mkdir ${HOME}/.config ; cp -a
  ${HOME}/.xchat2 ${HOME}/.config/hexchat
  
  I'd like to see your opinion on this matter as long as you have one
  you'd like to share with me ;) Furthermore I would shift my
  attention from the xchat package to hexchat seeing that it
  currently gets proxy maintained. If there's no objection I'd like
  to become the new contact of the person currently maintaining the
  package in portage.
  
  I also planned to release a news through the portage news system as
  soon as I lastrite xchat so people know how to move over to
  hexchat. As I never did this before I'd like to have some help
  concerning this matter. Is there some documentation about portage
  news?
  
  Regards
  
  
  [1] https://bugs.gentoo.org/394657 [2]
  https://bugs.gentoo.org/257006
 
 That's a pity. I was just about to step forward to rescue
 net-irc/xchat-xsys from treecleaning.

How about migrating xchat-xsys to hexchat?

 Do xchat plugins work in hexchat?

That's something for me to find out as well. I maintain the xchat-otr plugin 
which I would like to continue using in hexchat.
 
 Maybe we could just hardmask it. I see some ebuilds in the tree being
 hardmasked due to security bugs, but not removed which is ok to me.

-- 
Lars Wendler (Polynomial-C)
Gentoo package maintainer and bug-wrangler



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

Re: [gentoo-dev] net-irc/xchat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 

 Do xchat plugins work in hexchat?
 
 That's something for me to find out as well. I maintain the
 xchat-otr plugin which I would like to continue using in hexchat.
 

just tested xchat-xsys on hexchat and it does work, all commands afais
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQso8IAAoJEFpvPKfnPDWzTioH/iSFYPbIMdeiqbekbaHDPsCB
RrjoR8krxWhmQW7RvecdwM8hefHY/c6I6SdMPGDkpsBqCAdgFjvcDC2l486pqyWN
K+oFr66/lS2J5cHBcYX19w6kaeNZv25kDVs6t0AtqQxqROIpMnJl7UZ3jsexEBn2
by5dmqF8viSnfTXOsFm3//xDewBigTd6PkZfGoVxUmHkS5QoQS5R9HOA2m9uBWEj
nP9FbxfE0jMsHYzhZp9vuUwYLUPTpD8wNdImloFTn1uuFth39zHkjjNlgGGZkNB9
snVtEV5mUnZNclNfR1XNCGyOIcXqnHi4R8IwcUPK01KlEirU7BEIqyA/Qx1xPiA=
=uCoF
-END PGP SIGNATURE-

Re: [gentoo-dev] net-irc/xchat

2012-11-25 Thread Mike Frysinger

On Sun, Nov 25, 2012 at 3:27 PM, Lars Wendler wrote:
 I also planned to release a news through the portage news system as soon as I
 lastrite xchat so people know how to move over to hexchat. As I never did this
 before I'd like to have some help concerning this matter. Is there some
 documentation about portage news?

use profiles/updates/ to move xchat to hexchat ...
-mike

Re: [gentoo-dev] open season on other-dev's packages -- policy change?