[gentoo-dev] Farewell Gentoo.

2016-08-08 Thread Jesus Rivero (Neurogeek)
After so many years of being a proud Gentoo dev, it comes that time when I
have to say bye (at least for now).

There are no words to describe what Gentoo and being a Gentoo dev meant for
me.
I've made really good friends, learned a ton of skills in many facets of
computing from incredibly amazing and knowledgable people, and was a big
part of me getting great job opportunities.

I didn't want to part without first saying thanks to all the devs that have
and continue to make Gentoo such an amazing project. Keep making Gentoo
better!

Keep in touch.
Farewell, and thanks!

-- 
Jesus Rivero (Neurogeek)
(former-)Gentoo Developer


Re: [gentoo-dev] [Proposal] Eclass for nodejs modules

2016-02-29 Thread Jesus Rivero (Neurogeek)
On Mon, Feb 29, 2016 at 7:00 PM, Michael Orlitzky <m...@gentoo.org> wrote:

> On 02/29/2016 06:24 PM, Andrew Udvare wrote:
> > On 29/02/16 03:23, Geaaru wrote:
> >>
> >> In conclusion, it seems that is not accepted use of nodejs modules
> >> ebuild inside portage. It is right?
> >>
> >>
> > There used to be a CoffeeScript ebuild if you search back. I do not
> > remember how it worked but IIRC I think it was basically just creating a
> > fake root for itself. The distfile itself was just that node_modules/
> > directory in a tarball. No direction on how those dependencies could be
> > shared, so it is no longer in the tree.
> >
>
> I really needed it for one program, so I'm maintaining coffee-script in
> the tree now as dev-lang/coffee-script. I have an eclass and some
> ebuilds using it at https://github.com/orlitzky/npm but I didn't want to
> wind up in charge of a NodeJS project and nobody else did either, so I'm
> no longer working on it. The current coffee-script ebuild copy/pastes
> some of the stuff that would have been handled by the eclass.
>
> Only misery lies down this path.

Couldn't have said it better. Many of us have tried:
https://github.com/neurogeek/g-npm
https://github.com/neurogeek/gentoo-overlay/tree/master/dev-nodejs

npm just doesn't care about "global" installs, so it is broken by design
for any centralized package manager:
https://github.com/gruntjs/grunt/issues/438

Just use npm.


> Every upstream project is a mess and
> nobody cares, because implicitly, their roadmaps all involve realizing
> that javascript is awful and abandoning the project. To get this stuff
> in the tree, we would need a full-time devoted developer who just loves
> javascript and is sexually aroused by having his time wasted.
>
>
>


-- 
Jesus Rivero (Neurogeek)
Gentoo Developer


Re: [gentoo-dev] NPM / NodeJS project

2015-06-30 Thread Jesus Rivero (Neurogeek)
FWIW, I also bumped into this in my previous job.
I even wrote this (https://github.com/neurogeek/g-npm) which is incomplete
but saved me a bunch of time creating a crazy amount of npm ebuilds.

kinda rant
My experience is, this isn't worth it. npm is a mess, is
maintainer-unfriendly (although it might be argued that it is
developer-friendly) and they basically don't care about about distributions
at all.
npm packages are not meant to be installed globally. They are content with
having duplicate dependencies laying around everywhere.

Their semantic versioning sucks. They 1.4.1.2 can break backwards
compatibility with 1.4.1.1 and nobody cares.
I didn't find a way to download specific versions, and had trouble when
they did stuff like depend on 1.4.x, because of the above.

Also, although minor point, the other reason I stopped pursuing this was
because I think npm packages are needlessly small. So, you might want to
install a package that depends on tens of other packages that depend on
tens of packages themselves. Most of this packages are 10 lines of code.
So, I ended up real fat with an dev-nodejs category with over a hundred
packages.
/kinda rant

Having said all that, this was at least a couple of years ago. They might
have come to their senses by now.

Cheers,

On Tue, Jun 30, 2015 at 10:06 AM, Michael Orlitzky m...@gentoo.org wrote:

 On 06/30/2015 03:56 AM, Ian Delaney wrote:
 
  Is this what I prompted about a year or more ago, and drew no interest
  in pursuing the npm path?  I cited an eclass called npm.eclass in a
  dev's overlay. The conclusion was that using npm to install anything
  competed with portage at a level that made it a 'no go'. This came
  from members of the portage 'team'. It is a very awkward topic.
 

 No, but we may have wound up with a similar idea. I only became
 interested last week when somebody gave me a coffeescript program to
 deploy at work and there was no coffeescript.

 My eclass isn't using npm to do the actual install, since npm won't do a
 global install. I am using it as a lazy way to run the test suite (npm
 test), and I'm defaulting to npmjs.org as HOMEPAGE/SRC_URI because they
 have nice predictable URLs. But the src_install manually copies the
 javascript bits to a location where node can find them.





-- 
Jesus Rivero (Neurogeek)
Gentoo Developer


Re: [gentoo-dev] Fw: reviewboard and its bugs

2014-08-20 Thread Jesus Rivero (Neurogeek)
 electing to use this js 'toolchain'.  While I normally go to any
 lengths to maintain any and all packages within the python realm, this
 reviewboard has gone way beyond that realm. Until this, its
 underbelly was pure python and posed no real problem. Now I have a
 growing and unwelcome list of bugs of this package assigned to me as
 the sole remaining maintainer which are now unworkable.

 The real problem here is that there is an apparent keen set of would
 be users of this package, one of whom is a gentoo dev, who is to be
 found in at least one of those bugs.  To delete or mask the package
 amounts to a clean solution, and also abandons gentoo users looking
 to have the package made work for them.

 In summary, because of changes to reviewboard upstream, we need a new
 eclass and category to write ebuilds to these packages and add them to
 portage.



 --
 kind regards

 Ian Delaney


 --
 kind regards

 Ian Delaney




 --
 http://timboudreau.com




-- 
Jesus Rivero (Neurogeek)
Gentoo Developer


Re: tl;dr: [gentoo-dev] Fw: reviewboard and its bugs

2014-08-19 Thread Jesus Rivero (Neurogeek)
On Tue, Aug 19, 2014 at 9:37 PM, Alex Xu alex_y...@yahoo.ca wrote:

 tl;dr: python package has nodejs dependencies, we don't have a mechanism
 like distutils.eclass to install those system-wide.

 I gave this a try some time ago and was bummed down by some things. I dont
like nodejs enough, and npm devs seems to not care about centrally/globally
installed packages. There are some npm packages that have to be modified so
they can work when globally installed and it gets boring after a while. npm
packages tend to be really small so one package can have a really high
number of deps.

If anybody is interested in this, check out my repo with npm packages[0]
and a really simple g-npm tool[1] to generate ebuilds for them. These tools
might be outdated cause I don't use nodejs anymore and I dont care much
about it.

Feel free to ping me if you have questions.

Cheers,

[0] https://github.com/neurogeek/gentoo-overlay (I might have something
more recent somewhere)
[1] https://github.com/neurogeek/g-npm

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer


[gentoo-dev] Packages up for grabs

2014-06-04 Thread Jesus Rivero (Neurogeek)
Due to a mix of not currently using them, not much time available and
Upstreams has a completely different concept of packaging, the following
packages have been marked maintainer-needed and are up for grabs:

net-libs/ptlib
net-libs/opal
net-voip/ekiga
app-admin/chef
app-admin/chef-expander
app-admin/chef-server
app-admin/chef-server-api
app-admin/chef-server-webui
app-admin/chef-solr

Hoping these poor souls find a new, loving, home.

Cheers,

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer


[gentoo-portage-dev] Heads-up regarding dbapi/vartree.py: dblink._unmerge_pkgfiles

2014-01-28 Thread Jesus Rivero (Neurogeek)
Hi all,

I've been working on bugs
  https://bugs.gentoo.org/291589 and
  https://bugs.gentoo.org/346203

And that led me to start thinking/attempting to refactor a bit the way
dblink._unmerge_pkgfiles does things.

I've done few things to try and figure out how the whole function works,
not heavy coding yet.
So, if anybody is working on vartree.py, particularly with dblink and/or
_unmerge_pkgfiles let me know so we don't block or mess each other plans.

Cheers,

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer


Re: [gentoo-portage-dev] [PATCH 2/3 v2] Have repoman check that a package directory contains at least one ebuild (bug #245305).

2014-01-17 Thread Jesus Rivero (Neurogeek)
On Fri, Jan 17, 2014 at 4:36 PM, Tom Wijsman tom...@gentoo.org wrote:

 ---
  bin/repoman   | 8 
  man/repoman.1 | 3 +++
  2 files changed, 11 insertions(+)

 diff --git a/bin/repoman b/bin/repoman
 index d1542e9..44f3d3d 100755
 --- a/bin/repoman
 +++ b/bin/repoman
 @@ -326,6 +326,7 @@ qahelp = {
 SRC_URI.mirror: A uri listed in profiles/thirdpartymirrors is
 found in SRC_URI,
 ebuild.syntax: Error generating cache entry for ebuild;
 typically caused by ebuild syntax error or digest verification failure,
 ebuild.output: A simple sourcing of the ebuild produces output;
 this breaks ebuild policy.,
 +   ebuild.missing: A package directory must at least contain one
 ebuild or be treecleaned.,
 ebuild.nesteddie: Placing 'die' inside ( ) prints an error, but
 doesn't stop the ebuild.,
 variable.invalidchar: A variable contains an invalid character
 that is not part of the ASCII character set,
 variable.readonly: Assigning a readonly variable,
 @@ -1442,6 +1443,13 @@ for x in effective_scanlist:
 can_force = False
 continue

 +   if not ebuildlist:
 +   stats[ebuild.missing] += 1
 +   fails[ebuild.missing].append(%s must at least contain
 one  % x + \
 +   ebuild or be treecleaned.)
 +   can_force = False
 +   continue
 +
 # Sort ebuilds in ascending order for the KEYWORDS.dropped check.
 ebuildlist = sorted(pkgs.values())
 ebuildlist = [pkg.pf for pkg in ebuildlist]
 diff --git a/man/repoman.1 b/man/repoman.1
 index a78f94e..6315ea9 100644
 --- a/man/repoman.1
 +++ b/man/repoman.1
 @@ -301,6 +301,9 @@ Ebuilds that exist but have not been added to cvs
  .B ebuild.output
  A simple sourcing of the ebuild produces output; this breaks ebuild
 policy.
  .TP
 +.B ebuild.missing
 +A package directory must at least contain one ebuild or be treecleaned.
 +.TP
  .B ebuild.patches
  PATCHES variable should be a bash array to ensure white space safety
  .TP
 --
 1.8.5.2



Looks fine.

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer


Re: [gentoo-portage-dev] Signing off patches

2014-01-16 Thread Jesus Rivero (Neurogeek)
On Thu, Jan 16, 2014 at 12:44 PM, Alexander Berntsen
alexan...@plaimi.netwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 16/01/14 18:24, Jesus Rivero (Neurogeek) wrote:
  So, how would this work with emails to this list, exactly? An
  email should be sent any time one of those fields is changed?
 That's not necessary, in my opinion. We already send emails, looks OK
 to me and similar. And most patches don't really need more than one
 review and an ACK by the lead.

  Do you have a more detailed plan on how would this work?
 Not really. We're small enough to do this organically and on a
 per-case basis.

 But basically, if someone authors a non-trivial patch, that person
 should *never* push themselves. Whoever reviews it should push it,
 adding the Reviewed-by field. The reviewer should also get an ACK by
 the team lead (via IRC or whatever) and add that to the commit before
 pushing.


Gotcha!, that makes sense to me.


 In a bigger project (or with a team lead with a lot of free time...),
 I would argue that the reviewer should send the new commit, with the
 Reviewed-by field added, to the team lead, which then adds the
 Acked-by field themselves, before pushing. I'm not convinced the
 benefits of this extra step outweighs the drawback in the overhead of
 this small community of ours.

 - --
 Alexander
 alexan...@plaimi.net
 http://plaimi.net/~alexander
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.22 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iF4EAREIAAYFAlLYGpkACgkQRtClrXBQc7WA4AEAmghIHMkNxiqJ79CONZzs/k/u
 t0QoASddzlSruejiVaQA+QFOdbgMaA59hf9DInPAgpG7Kc6fbFENgkZn4jEY9NAq
 =CrCK
 -END PGP SIGNATURE-


Thanks,

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer


Re: [gentoo-portage-dev] [PATCH 3/3] Have repoman deprecate G2CONF for the GNOME team. (bug #482084).

2014-01-15 Thread Jesus Rivero (Neurogeek)
On Jan 15, 2014 7:08 PM, Tom Wijsman tom...@gentoo.org wrote:

 ---
  bin/repoman   |  2 ++
  man/repoman.1 |  3 +++
  pym/repoman/checks.py | 10 ++
  3 files changed, 15 insertions(+)

 diff --git a/bin/repoman b/bin/repoman
 index 3263ceb..6754edd 100755
 --- a/bin/repoman
 +++ b/bin/repoman
 @@ -318,6 +318,7 @@ qahelp = {
 EAPI.incompatible: Ebuilds that use features that are only
available with a different EAPI,
 EAPI.unsupported: Ebuilds that have an unsupported EAPI
version (you must upgrade portage),
 SLOT.invalid: Ebuilds that have a missing or invalid SLOT
variable value,
 +   G2CONF.deprecated: G2CONF is deprecated, see Gentoo bug
#482084 and the GNOME team policies,
 HOMEPAGE.missing: Ebuilds that have a missing or empty
HOMEPAGE variable,
 HOMEPAGE.virtual: Virtuals that have a non-empty HOMEPAGE
variable,
 PDEPEND.suspect: PDEPEND contains a package that usually only
belongs in DEPEND.,
 @@ -382,6 +383,7 @@ qawarnings = set((
  dependency.badtilde,
  DESCRIPTION.toolong,
  EAPI.deprecated,
 +G2CONF.deprecated,
  HOMEPAGE.virtual,
  LICENSE.deprecated,
  LICENSE.virtual,
 diff --git a/man/repoman.1 b/man/repoman.1
 index 2bf3765..7ec43d5 100644
 --- a/man/repoman.1
 +++ b/man/repoman.1
 @@ -227,6 +227,9 @@ Syntax error in RESTRICT (usually an extra/missing
space/parenthesis)
  .B SLOT.invalid
  Ebuilds that have a missing or invalid SLOT variable value
  .TP
 +.B G2CONF.deprecated
 +G2CONF is deprecated, see Gentoo bug #482084 and the GNOME team policies
 +.TP
  .B SRC_URI.mirror
  A uri listed in profiles/thirdpartymirrors is found in SRC_URI
  .TP
 diff --git a/pym/repoman/checks.py b/pym/repoman/checks.py
 index 85aa065..c2608b0 100644
 --- a/pym/repoman/checks.py
 +++ b/pym/repoman/checks.py
 @@ -799,6 +799,16 @@ class PortageInternalVariableAssignment(LineCheck):
 e += ' on line: %d'
 return e

 +class DeprecateG2CONF(LineCheck):
 +   repoman_check_name = 'G2CONF.deprecated'
 +   re = re.compile(r'.*G2CONF.*')
 +
 +   def check(self, num, line):
 +   Run the check on line and return error if there is
one
 +   m = self.re.match(line)
 +   if m is not None:
 +   return (G2CONF on line %d is deprecated, see
Gentoo bug #482084.)
Are you missing the line number interpolation here? or %d is supposed to be
returned?
 +
  _base_check_classes = (InheritEclass, LineCheck, PhaseCheck)
  _constant_checks = None

 --
 1.8.5.2


Other than that, Looks good to me.


[gentoo-portage-dev] [PATCH v3] Added support for variable expansion in source command argument in make.conf

2014-01-13 Thread Jesus Rivero
Signed-off-by: Jesus Rivero neurog...@gentoo.org
---
 pym/portage/tests/util/make.conf.example.source_test |  6 ++
 .../tests/util/make.conf.example.source_test_after   |  7 +++
 pym/portage/tests/util/test_getconfig.py | 20 
 pym/portage/util/__init__.py |  7 ++-
 4 files changed, 39 insertions(+), 1 deletion(-)
 create mode 100644 pym/portage/tests/util/make.conf.example.source_test
 create mode 100644 pym/portage/tests/util/make.conf.example.source_test_after

diff --git a/pym/portage/tests/util/make.conf.example.source_test 
b/pym/portage/tests/util/make.conf.example.source_test
new file mode 100644
index 000..c0b1c16
--- /dev/null
+++ b/pym/portage/tests/util/make.conf.example.source_test
@@ -0,0 +1,6 @@
+# Copyright 1999-2014 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# Contains local system settings for Portage system
+
+# Test make.conf for variable expansion in source tokens.
+source $PORTAGE_BASE_PATH/make.conf.example.source_test_after
diff --git a/pym/portage/tests/util/make.conf.example.source_test_after 
b/pym/portage/tests/util/make.conf.example.source_test_after
new file mode 100644
index 000..e41913e
--- /dev/null
+++ b/pym/portage/tests/util/make.conf.example.source_test_after
@@ -0,0 +1,7 @@
+# Copyright 1999-2014 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# Contains local system settings for Portage system
+
+# Test make.conf for variable expansion in source tokens.
+# We should see this variable in getconfig result
+PASSES_SOURCING_TEST=True
diff --git a/pym/portage/tests/util/test_getconfig.py 
b/pym/portage/tests/util/test_getconfig.py
index c7ab360..bffbc4f 100644
--- a/pym/portage/tests/util/test_getconfig.py
+++ b/pym/portage/tests/util/test_getconfig.py
@@ -8,6 +8,7 @@ from portage import _unicode_encode
 from portage.const import PORTAGE_BASE_PATH
 from portage.tests import TestCase
 from portage.util import getconfig
+from portage.exception import ParseError
 
 class GetConfigTestCase(TestCase):

@@ -31,6 +32,25 @@ class GetConfigTestCase(TestCase):
for k, v in self._cases.items():
self.assertEqual(d[k], v)
 
+   def testGetConfigSourceLex(self):
+
+   base = os.path.dirname(__file__)
+   make_conf_file = os.path.join(base,
+   'make.conf.example.source_test')
+
+   d = getconfig(make_conf_file,
+   allow_sourcing=True, expand={PORTAGE_BASE_PATH : 
base})
+
+   # PASSES_SOURCING_TEST should exist in getconfig result
+   self.assertIsNotNone(d)
+   self.assertEqual(True, d['PASSES_SOURCING_TEST'])
+
+   # With allow_sourcing : True and empty expand map, this should
+   # Throw a FileNotFound exception
+   self.assertRaisesMsg(An empty expand map should throw an 
exception,
+   ParseError, getconfig, *(make_conf_file,),
+   **{'allow_sourcing' : True, 'expand' : {}})
+
def testGetConfigProfileEnv(self):
# Test the mode which is used to parse /etc/env.d and 
/etc/profile.env.
 
diff --git a/pym/portage/util/__init__.py b/pym/portage/util/__init__.py
index 24553da..0799487 100644
--- a/pym/portage/util/__init__.py
+++ b/pym/portage/util/__init__.py
@@ -593,8 +593,13 @@ class _getconfig_shlex(shlex.shlex):
shlex.shlex.__init__(self, **kwargs)
self.__portage_tolerant = portage_tolerant
 
+   def allow_sourcing(self, var_expand_map):
+   self.source = portage._native_string(source)
+   self.var_expand_map = var_expand_map
+
def sourcehook(self, newfile):
try:
+   newfile = varexpand(newfile, self.var_expand_map)
return shlex.shlex.sourcehook(self, newfile)
except EnvironmentError as e:
if e.errno == PermissionDenied.errno:
@@ -694,7 +699,7 @@ def getconfig(mycfg, tolerant=False, allow_sourcing=False, 
expand=True,
string.ascii_letters + ~!@#$%*_\:;?,./-+{})
lex.quotes = portage._native_string(\')
if allow_sourcing:
-   lex.source = portage._native_string(source)
+   lex.allow_sourcing(expand_map)
 
while True:
key = _unicode_decode(lex.get_token())
-- 
1.8.3.2




[gentoo-portage-dev] [PATCH] Added support for variable expansion in source command. wrt bug #490896

2014-01-12 Thread Jesus Rivero (Neurogeek)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

Attached is a patch to allow variables in the argument for the source
command in make.conf
The implementation refactors what happens when allow_sourcing is True in
the portage.util.getconfig
function. Instead of just setting lex.source, now we also pass the
expand_map dict.

This patch fixes bug #490896

Jesus Rivero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAlLS5XgACgkQdIssYB9vBoOUoQCdFA2JfPHvjLDVp0mqDTo01Z9E
wMoAmgJLflNFTb9JoSnOJzZga6oJckYI
=3Atz
-END PGP SIGNATURE-


0001-Added-support-for-variable-expansion-in-source-command.patch
Description: Binary data


[gentoo-portage-dev] [PATCH] [REV] Added support for variable expansion in source command. wrt bug #490896

2014-01-12 Thread Jesus Rivero (Neurogeek)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

In the previous patch, I didn't notice an error in the unittest I wrote for
the feature.
Attached is the correct patch, please disregard the previous one.

Cheers,

Jesus Rivero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAlLS7oQACgkQdIssYB9vBoP5wgCgh0kIe28oKg5XECPkjoe36QaH
oY8An0iUVqvPi5cftWbpbrHO2nSsUcqz
=wZnl
-END PGP SIGNATURE-


0002-Added-support-for-variable-expansion-in-source-command.patch
Description: Binary data


Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages

2013-01-03 Thread Jesus Rivero (Neurogeek)
On Jan 3, 2013 6:54 AM, Pacho Ramos pa...@gentoo.org wrote:

 El jue, 03-01-2013 a las 12:41 +0100, Pacho Ramos escribió:
 [...]
  Well, I was referring to this exact case as voip team already pointed
  they weren't looking to ekiga stuff and, then, didn't had much sense to
  me to see bugs assigned to them instead of real maintainer (will commit
  access)

 will - with

Pacho, I have been taking care of ekiga, ptlib and opal. Feel free to make
me the assignee for bugs in those packages.

I should be on metadata for those...


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

2012-12-01 Thread Jesus Rivero (Neurogeek)
On Dec 1, 2012 5:01 AM, Wolfram Schlich wschl...@gentoo.org wrote:

 Hi!

 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:

 sys-block/tw_cli(3ware)
 dev-db/mysql-proxy

 If you're interested in any of these, just contact me directly.

 Thanks!

 Cheers,
 Wolfram


I'll take these.

Cheers,


Re: [gentoo-dev] Packages up for grabs due apache herd removal

2012-11-27 Thread Jesus Rivero (Neurogeek)
On Tue, Nov 27, 2012 at 2:43 PM, Pacho Ramos pa...@gentoo.org wrote:
 www-apache/mod_fastcgi
 www-apache/mod_fastcgi_handler
app-admin/apachetop

Took these 3.

Cheers,



-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages

2012-10-10 Thread Jesus Rivero (Neurogeek)
On Wed, Oct 10, 2012 at 5:53 PM, Chí-Thanh Christopher Nguyễn
chith...@gentoo.org wrote:
 Pacho Ramos schrieb:
 I am noticing for a long time that bugs related with ekiga,
 opal, yate... are completely unattended by voip team for
 years. If nobody from that team is willing to maintain
 them, please move them to maintainer-needed to, at least,
 reflect reality.

 Any news here? I can move that packages to maintainer-needed if you
 send me the list of packages you don't want to maintain. Also,
 maybe telepathy stuff could be moved to its own herd (that is
 basically gnome team + tester... or maybe tester could join gnome
 team ;))

 There is now one proxy maintainer for a couple of packages, he is
 currently waiting for voip overlay access in bug 437538. He will take
 care of linphone and related packages (see bug 399735 and its
 dependencies).

 Regarding the packages that can be moved to maintainer-needed: I think
 a good heuristic is if the package has several open bugs with no
 maintainer reaction, and hasn't been touched by anyone from voip herd
 in over a year. This would include the ekiga, opal and yate packages
 mentioned above.

I'd gladly take maintainership of opal and ekiga, if nobody wants them.

Cheers,

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



Re: [gentoo-dev] news item: changes to stages (make.conf and make.profile)

2012-07-23 Thread Jesus Rivero (Neurogeek)
On Jul 23, 2012 9:43 PM, Brian Dolbec dol...@gentoo.org wrote:

 On Mon, 2012-07-23 at 20:28 -0400, Rick Zero_Chaos Farina wrote:

  A lot of things, app-portage/ufed for example, don't support this yet...
 

 ufed is on the endanged species list, along with a few other app-portage
 utilities. It hasn't been developed or maintained for some time now.  If
 it is to survive, It'll need someone to step up and update it.

I don't see a bug for this change for ufed.

I can take care of this change in ufed.

 --
 Brian Dolbec dol...@gentoo.org


Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags

2012-05-05 Thread Jesus Rivero (Neurogeek)
On May 5, 2012 3:14 PM, Markos Chandras hwoar...@gentoo.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 On 05/05/2012 06:10 PM, Alec Warner wrote:
  On Sat, May 5, 2012 at 5:31 PM, Maxim Koltsov
  maksbo...@gentoo.org wrote:
  Hi, I just installed fresh system on my pc, selected
  'default/linux/x86/10.0/desktop' profile and noticed ldap among
  default USE flags. Why is that needed? I suppose there are more
  users w/o ldap auth on desktops than with it. So my proposal is
  to remove it from profiles/targets/desktop/make.defaults. Any
  objections?
 
 
  So how are you going to avoid destroying machines that rely on it
  being on by default?
 
  -A
 
 Users will note the use flag change when they run emerge -uDN world
 and they will add it to their make.conf. I am also in favor of
 dropping ldap from the desktop profiles.

I don't like this change much. There are valid use cases for an ldap use
flag in the desktop profile that could break easily with this change.

Also, you could make the same case for adding -ldap to your make.conf

 - --
 Regards,
 Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.19 (GNU/Linux)

 iQIcBAEBCgAGBQJPpXuaAAoJEPqDWhW0r/LCJUIP/iwaCfKl5VAQaecbeHD3UnsE
 bvQidUoVOSCEYUaMd7cjmMi2vGpQ5JbYFOedy/tsdiFmuL8ACL8WqtKgfd9j8VGX
 D+hK2QOGx6YKYYYG+QLbU0TaKa95pMK9eQibVeTu+1ptzI9TGUdmbm675FpTn4WL
 ibJAuVESJZWYnbH2rJf8OHCx1J/Re4vBGH9p8s/F8znzAaXcpTFi7HgObXXsVPLA
 AIgUWgsmEcHTQLq83Y79HJhF8h0Y2cUC57icc0ZnVzjHyF10ll//AsDhuFP2ToSp
 NBK+U4tc0NDBdrnyEYSEkEY1DXyXvKp4O6i9bbaFsVnj45Bf8sRPmjRBE2HOcyGJ
 WfZO+tVKnxOfeLeUQ+47jwHmMyyBb6t7YCgX71S17oqOqm+0aV/GmNHPYR9+HxQY
 h1sFHyrkQ8Yh9GtfOn4r6L0YdV2LDP13MaqnOUONwpLN7UWOvv2dhWQDY4iikomh
 2nLPtHKmChu5HsRfNIRvOPYt4YGjZFtPX2BoKXveWwEsreeZG3Nr0SPIuKubAnKJ
 Sx1Up190ElkNPHdYLIemVOjBoe+R0AGs/QxjTfFhSGog1etWsS4Sm287wqdxkbQo
 HHwSG1zIVMyr7IZEuEOgyEVY9ZTmVA4vSaUPZIv5KLq5o3MdrvPHEkT29lPgcaUZ
 xssurey2d7C0S5j9//SL
 =vd37
 -END PGP SIGNATURE-



Re: [gentoo-dev] Looking for (Common) Lisp shepherds

2012-03-16 Thread Jesus Rivero (Neurogeek)
Hi Marijn,

Count me in. I've recently found a strong affection for Lisp, and
although Im a total Lisp noob, I can use this experience to learn more
about it. It would be pretty awesome.

Where do I start?

On Fri, Mar 16, 2012 at 10:09 AM, Marijn hk...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi,

 the Gentoo Lisp project is having trouble maintaining Common Lisp
 packages and to a lesser extent Scheme packages due to a lack of
 time/interest of the people currently working on that. Most of those
 packages are leaf packages, but some are not: mostly dev-scheme/guile
 and dev-lisp/sbcl (Steel Bank Common Lisp compiler) I think. Many
 Common Lisp packages have been maintained in our overlay (mostly
 thanks to Stelian Ionescu (fe[nl]ix)) including SBCL but not much has
 moved to main tree.
 With this email I am hoping to achieve (in order of preference) that
 either some people with an interest in the Lisp family of programming
 languages join our team to help us out, or some people (without said
 broader interest?) take over primary responsibility for non-leaf
 packages that are suffering, with the Lisp team taking a back seat.

 People interested in joining us can contact us on our mailing list
 gentoo-l...@lists.gentoo.org or on freenode in our channel #gentoo-lisp.

 Marijn
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.18 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk9jSbMACgkQp/VmCx0OL2zuUACgp/Zg56jDxPwIIMGfmg8NJ7OD
 /V0AmgIvcCIJ1+iBtJBkHoSgC/UIuK98
 =Q5/8
 -END PGP SIGNATURE-




-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



Re: [gentoo-dev] Packages up for grabs

2011-11-11 Thread Jesus Rivero (Neurogeek)
2011/11/11 Tomáš Chvátal scarab...@gentoo.org:
 Hello guys,

 As my only Gentoo installation is libreoffice test virtual I am not
 able to really care about these.

 So these packages are up for grabs if anyone finds them interesting:

 app-misc/dsgui
 app-misc/klavaro
 dev-cpp/yaml-cpp
 dev-libs/softhsm
 dev-ruby/dnsruby
 net-dns/opendnssec
 net-libs/dslib
 net-libs/libisds
 net-misc/shigofumi
 sys-devel/autoconf-archive

 Have fun

 Tom

I'll take dev-cpp/yaml-cpp.

Best regards,





-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying

2011-10-15 Thread Jesus Rivero (Neurogeek)
On Fri, Oct 14, 2011 at 9:54 PM, Mike Gilbert flop...@gentoo.org wrote:
 On 10/14/2011 09:11 PM, Paweł Hajdan, Jr. wrote:
 On 10/14/11 5:38 PM, Alec Warner wrote:
 I believe op's point is that there is no one to escalate the problem
 to; certainly the council members are not going to do the work
 themselves and we already have our best people on it.

 I'm aware of that. My point is that I think there are many scenarios in
 which EAPI-4 + python.eclass can work, especially if it's used only for
 few things in cases like www-client/chromium

 Because the python team takes _ages_ to do the transition that is
 holding back many other packages, because they've made python.eclass
 overly complex and now try to make it perfect,

 I'd just like to get an OK to enable EAPI-4 for that eclass.

 Please note that it's still up to dependent packages which EAPI they
 use. If they break python.eclass with EAPI-4 they shouldn't update to
 that EAPI. However, if there are packages using python.eclass that could
 work fine with EAPI-4, it shouldn't be blocking them for *ages*


 That would be an ok approach from my perspective: We could just change
 line 14 of python.eclass and let package maintainers report breakage as
 they increment EAPI. I am confident that nothing EAPI = 3 would break.

 Is anyone (especially djc and the python herd members) opposed to this?



Sorry I wasn't able to post before. But...
This can be done and in fact has been discussed before, just allow
ebuild to not die with EAPI=4, but this doesn do anything at all, just
not die on EAPI=4. All the features and the good stuff just won't be
there as other use cases need (as Robin and Tony mentioned).

We've been working on a redesign of the eclass but is nothing like
stealing candy from a kid, there are many things involved, such as the
large amount of Python ABIs that people use regularly, distutils
quirks, current eclass complexity, among others that make it quite
challenging to come up with something new.

I'm all up for making eclass accept EAPI=4 ebuilds, but to fully
implement EAPI=4 fesatures, I'm going to have to ask you guys for a
bit of more patience. I know you have done just that, being patient,
but just a bit more. I know we can deliver a solution for this soon
enough.

Best regards,

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



Re: [gentoo-dev] Packages up for grabs due cbrannon retirement

2011-09-13 Thread Jesus Rivero (Neurogeek)
On Tue, Sep 13, 2011 at 3:24 PM, Pacho Ramos pa...@gentoo.org wrote:
 Due cbrannon retirement the following packages need a new maintainer:

 dev-db/unixODBC

I'll take dev-db/unixODBC

Thanks,

 net-misc/telnet-bsd

 Thanks for taking them










-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



Re: [gentoo-dev] Packages up for grabs due cbrannon retirement

2011-09-13 Thread Jesus Rivero (Neurogeek)
On Tue, Sep 13, 2011 at 4:39 PM, Anthony G. Basile bluen...@gentoo.org wrote:
 On 09/13/2011 03:24 PM, Pacho Ramos wrote:
 Due cbrannon retirement the following packages need a new maintainer:

 dev-db/unixODBC

 I've use this and don't want to see it rot.  If no one wants it, I'll
 give it love.  I have no strong feelings about maintaining it, so if
 someone else wants to, fine by me, as long as it stays alive.

Hi Anthony,
I'm actively using it, so I took it.
Feel free to co-maintain if you want to.


Best regards,


 --
 Anthony G. Basile, Ph.D.
 Gentoo Linux Developer [Hardened]
 E-Mail    : bluen...@gentoo.org
 GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
 GnuPG ID  : D0455535





-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



[gentoo-dev] Last rites for app-accessibility/speakup-utils

2011-09-01 Thread Jesus Rivero (Neurogeek)
# Jesus Rivero neurog...@gentoo.org (01 Sep 2011)
# Masked for removal in 30 days. This package does not
# work with any version of app-accessibility/speakup
# anymore.
app-accessibility/speakup-utils


-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



Re: [gentoo-dev] Packages up for grabs due dragonheart retirement

2011-07-22 Thread Jesus Rivero (Neurogeek)
On Wed, Jul 20, 2011 at 11:08 AM, Pacho Ramos pa...@gentoo.org wrote:
 Due dragonheart retirement the following packages need a new maintainer:

 dev-python/pyspf
 dev-python/python-lzo

Python team will take these two.

Best regards,
-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



Re: [gentoo-dev] Ohloh statistics updated

2011-07-22 Thread Jesus Rivero (Neurogeek)
2011/7/22 Stanislav Ochotnicky sochotni...@gentoo.org:
 Hello fellow devs,

 some of you know that our commit statistics at Ohloh[1] have been
 outdated because they were not able to process our huge CVS tree for
 some reason :-)

 One way or the other I managed to reuse robbat2's previous work on
 cvs-git conversion and keep our experimental conversion repository
 up-to-date (I don't have cron job, but it's still completely automated).

 After 3 weeks of crunching (or was it more?) Ohloh machines finally spit
 out updated statistics, removing few warnings from our project page
 (such as Decreasing year-over-year development activity). Updates are
 faster of course so our stats shouldn't be outdated anymore.

 So go claim your commits,


Good job!
Thank you!


 [1] https://www.ohloh.net/p/gentoo
 [2] http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary

 --
 Stanislav Ochotnicky

 PGP: 7B087241
 jabber: stanis...@ochotnicky.com




-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



Re: [gentoo-dev] Packages up for grabs due truedfx retirement

2011-07-20 Thread Jesus Rivero (Neurogeek)
On Wed, Jul 20, 2011 at 12:34 PM, Pacho Ramos pa...@gentoo.org wrote:
 Due truedfx retirement the following packages need a new maintainer:

 app-editors/le
 app-editors/nvi
 app-editors/ted
 app-misc/glastree
 app-portage/cfg-update
 dev-libs/librep
 dev-libs/tvision
 dev-util/dialog
 x11-apps/xkbset


I'll take dev-util/dialog and app-editors/nvi


 Thanks for taking them







-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



Re: [gentoo-dev] Packages up for grabs due truedfx retirement

2011-07-20 Thread Jesus Rivero (Neurogeek)
On Wed, Jul 20, 2011 at 1:27 PM, Paul Varner fuzzy...@gentoo.org wrote:
 On Wed, 2011-07-20 at 18:34 +0200, Pacho Ramos wrote:
 Due truedfx retirement the following packages need a new maintainer:

 app-editors/le
 app-editors/nvi
 app-editors/ted
 app-misc/glastree
 app-portage/cfg-update
 dev-libs/librep
 dev-libs/tvision
 dev-util/dialog
 x11-apps/xkbset

 Additionally, the tools-portage team would be very appreciative if
 someone would be willing to do active maintenance on app-portage/ufed.
 The repository for it is at:

 http://git.overlays.gentoo.org/gitweb/?p=proj/ufed.git;a=summary

 Regards,
 Paul



Paul, I would love to. I'll take it



-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



[gentoo-dev] Last rites app-accessibility/speechd

2011-07-20 Thread Jesus Rivero (Neurogeek)
# Jesus Rivero neurog...@gentoo.org (20 Jul 2011)
# Really old and unmaintained package. Bug #360067.
# Removal in 30 days.
app-accessibility/speechd

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



Re: [gentoo-dev] The Python problem

2011-06-28 Thread Jesus Rivero (Neurogeek)
On Mon, Jun 27, 2011 at 7:58 AM, Dirkjan Ochtman d...@gentoo.org wrote:
 Hi guys,
[...]
 So I know a bunch of people have already looked at it, and I'd like to
 know: what do you find better about the Ruby approach compared to the
 Python approach? Is it just the size of python.eclass, or are there a
 number of other issues?

 Cheers,

 Dirkjan



Let´s start by agreeing with the complexity of the Python eclass. And
a heavy change right now, is going to be painful to say the least
because a great deal of packages have been adapted to work the way the
eclass works right now.

I agree with Grobian in what he said about the coding style of the
python.eclass, and would love to see that fixed. I also agree with
the redundancy of some variables and I think just using PYTHON_DEPEND
should be sufficient to let the PM know what should be done with a
specific package.

With python-updater, well, some time ago Ali Polatel implemented some
approaches to get rid of python-updater, by exporting some variable in
ebuilds that needed to be rebuilt when new python versions were
installed. I dont recall what happened with that, but we could think
of some ways to finally get rid of python-updater.

WRT python3, I too believe it is important to have it stable. Thing
is, for better or worse, upstream have it stable, and py2 and py3 are
going to co-exist for a long time. Thing is, we should really figure
out a way to have it stop messing things up. I believe with a proper
dependency handling in the eclass, we could get this to work.

As I said it already, we could start doing things simpler in the
current python.eclass and maybe that would attract some devs to help
out with it, as they find it more comfortable to work with.

Best regards,

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



Re: [gentoo-dev] Reviving webapp-config

2011-06-10 Thread Jesus Rivero (Neurogeek)
On Fri, Jun 10, 2011 at 7:49 AM, Sebastian Pipping sp...@gentoo.org wrote:
 Questions:

  - What does reviving mean in detail?
     A re-write?  A somewhat compatible re-write?
     Getting back to maintaining the current code?
     Why did you choose how you did?

  - Have you spoken to Andreas Nüsslein who worked on a
   re-write in context of an earlier GSoC?


IIRC, last year's GSoC featured a project involving the rewrite of
webapp-config. Andreas was the student, but I don't recall right now
who the mentor was. Maybe this would be a good start!

 Best,




 Sebastian



Best regards,

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer



[gentoo-dev] Re: Disabling auto-bumping of active Python version

2010-11-14 Thread Jesus Rivero (Neurogeek)
+1

I totally agree with the conclusion. I believe that choice, select
the active version of Python, should not be implied by us, but taken
by the user even if he explicitly asked for a new version to be
installed.

I've been in this situation before, and just because I wanted to try
some new cool features, sometimes I ended up with a semi broken system
just because I wouldn't take extra care with it.

Plus I think users are going to miss that feature much.

Best regards,

Jesus

On 11/14/10, Sebastian Pipping sp...@gentoo.org wrote:
 Hello,

 thanks for your interest.  This thread is not about Python 3.x in
 particular, in case you wonder.


 In this mail
 
 - Typical GCC update  (for comparison)
 - Python 2.7 update simulation  (and how it fails)
   - The scenario
   - What happens
   - How it happens
 - Conclusion


 Typical GCC update
 ==
 Before we look at Python, let's have a look at how it works with GCC:

   When a new version of GCC appears in Gentoo, it is installed into
   a new slot.  To activate the new version, you run gcc-config.
   In the meantime your system is in working state and continues to
   use the old version of GCC.


 Python 2.7 update simulation
 

 The scenario
 
 With Python it's very different.  Let's assume a system with Python 2.6
 as the only Python around.  Now we would like to run this command:

   # sudo emerge dev-lang/python:2.7 dev-python/pyinotify

 Assume that dev-lang/python:2.7 is unmasked already.
 The resulting system state now depends on these two factors:

  - Has pyinotify been installed to the system before our invocation of
emerge?  Depending on that, pyinotify may be installed first, or
python 2.7 may.   Let's assume pyinotify comes last.  The difference
is marginal.

  - Were we using USE_PYTHON in /etc/make.conf (e.g. USE_PYTHON=2.6)
or not?  I'll assume USE_PYTHON is not set manually and implied
during installation.  The last three devs I spoke to had not heard
of variable USE_PYTHON, so that assumption may work.


 What happens
 
 Steps taken by emerge:
 - Python 2.7 installed
 - Python 2.7 is made the active version of Python automatically
 - pyinotify is installed for Python ABI 2.7 (neither 2.6 nor both)

 Resulting system state:
 - Python 2.7 now is the main active version of Python
 - All Python packages except pyinotify are installed for Python ABI 2.6
 - pyinotify is the only package installed for Python ABI 2.7
 - before running python-updater larger parts of the system may be
   unusable


 How it happens
 --
 All dev-lang/python ebuilds run a Bash function called
 eselect_python_update at the beginning pkg_postinst stage.
 Former function wraps a call to

   eselect python update ${eselect_python_options}


 Conclusion
 ==
 When you update GCC your system stays at a healthy state.
 You trigger the switch of active versions.

 With Python, when you install a newer version if gets activated, leaving
 your system in broken state.  An update of Python always involves
 running python-updater.  If the user/admin has to run that anyway, why
 should we take the call to eselect python off his shoulders, especially
 we break the system doing so?

 So I plan to remove the call to eselect_python_update from all Python
 ebuilds in two weeks from now.  Besides Arfrever everybody I spoke to on
 this topic so far agreed to this approach.  The two weeks window are to
 give people room to think and discuss about it.

 Please try to keep this thread as low-heat as possible.
 Thanks for reading.



 Sebastian



-- 
Sent from my mobile device

Jesus Rivero
Gentoo Python Team



Re: [gentoo-dev] RFC: changing the developer profile: FEATURES=test - FEATURES=test-fail-continue

2010-06-04 Thread Jesus Rivero (Neurogeek)
Hi,

On Fri, Jun 4, 2010 at 10:41 AM, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
 What do you think about doing the following change in
 /usr/portage/profiles/targets/developer/make.defaults:

 replace test with test-fail-continue to make it just less
 frustrating (we still have a lot of test failures)

I've been thinking about this for a while. Some packages have tests
that are meant only for upstream in certain conditions
and are not meant to be ran during installing. As we have ARCH teams,
couldn't we think a way in which TEST teams can
be created? I mean, a bunch of devs only focused on making tests work
or just restrict them?

This team (or a Gentoo project) can work hand by hand with other teams
and ARCH members.

Is it even possible?


 Hopefully that will also make more of us use the developer profile, and
 detect test failures.

 What do you think?

 Paweł

Best regards,

-- 
Jesus Rivero (Neurogeek)



Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

2010-04-03 Thread Jesus Rivero (Neurogeek)
Hi guys,

On Sat, Apr 3, 2010 at 9:10 AM, Ben de Groot yng...@gentoo.org wrote:
 On 3 April 2010 13:33, Richard Freeman ri...@gentoo.org wrote:
 I really think that the Gentoo recruitment process needs improvement. Right
 now it seems like a LOT of effort is required both to become a Gentoo dev
 and to help somebody become a Gentoo dev.  That means we have great people,
 but not many of them.

 I agree. So what can we do to improve this process?

 I myself am not fond of the quizzes, and from what I've seen most
 recruits find them tedious as well. It can be quite demotivating,
 maybe because it reminds one too much of highschool or something.
 I took a long time myself to finish them, and that wouldn't have
 been necessary, as my mentors ensured me I was ready to become a
 dev. And I see the same thing happening with some of my own recruits.
 They can be ready, but  just find the quizzes a chore.


   I understand that quizzes serve a purpose and IMHO, are a good way
to face common issues when writing ebuilds. On the other hand, I
understand that quizzes are lengthy and could become a blocker in the
recruitment process (I have met at least two prospects drop out due to
the inability to finish them, being for lack of time to concentrate or
because they got bored by the chore.)

   Maybe if we could find the way to make the knowledge found in
quizzes be more exciting to new devs, then we could still have a
strong recruitment process without the burden of completing the
quizzes. So, what I propose is to transform the quizzes part of the
process into a list of tasks the prospect should complete in order to
gain the necessary ability to pass. This ability could be measured
in points or just by task completed.

   Then it gets interesting for them and for us. Those tasks could be
to tackle problems from the quizzes but in real ebuilds (prepared by
us for this, much as when recruiters ask us to clean some ebuild) or
could be tasks created by teams to specifically address common issues
in their domain if the prospect is trying to join them or shows an
interest on helping this specific team.

 Of course this doesn't address the organizational side of things, so
 we need to come up with something else for that.

   This doesn't address them either. But I really don't think this is
the main issue that causes the problem :) So I guess these questions
could remain in one easy quiz.

 --
 Ben de Groot
 Gentoo Linux Qt project lead developer



  If I can be of any assistance in this, I'll gladly help.

--
Jesus Rivero (Neurogeek)
Gentoo Python Team



Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force

2010-04-03 Thread Jesus Rivero (Neurogeek)
On Sat, Apr 3, 2010 at 5:54 PM, Sebastian Pipping sp...@gentoo.org wrote:
 I'm calling for participation in a new team working on things around
 reports, bug analysis, heartbeat tracking in Gentoo:


 Goals
 =
 - help track the heartbeat/breath of Gentoo
    (bugs fixed per day, bug distribution per herd, ..)

 - point to problems we may be overlooking in Gentoo
    (letting numbers speak to us and listening to them)

 - help to prioritize when distributing available resources
    (specific calls for help, people switching teams, ..)


 Data we will be working with
 
 - The Bug database  (XML from Bugzilla, ..)
 - Package tree history  (VCS logs, ..)
 - User setup details  (gentoo-smolt, ..)
 - ..


 Concrete tasks
 ==
 - bugday.g.o re-write  (work in progress)
 - work on association between bugs and packages
  (for all bugs, not just bugday ones)
 - get real numbers on how much active manpower we have


 People
 ==
 These poeple are in de facto:
 - deathwing00
 - sping
 - you here?

   Sebastian, count me in. I believe this sort of stuff, or small
parts of what you are mentioning, was done in the newsletter. I
believe this is something real nice we should put somewhere public.



 If this is stuff which
 - you have time for
 - you are good at

 please join us!



 Sebastian


   Best regards,

--
Jesus Rivero (Neurogeek)
Gentoo Python Team



[gentoo-dev] Last rites: dev-python/optik

2009-09-20 Thread Jesus Rivero (Neurogeek)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

 I have masked dev-python/optik for removal in 30 days as it is
bundled with =dev-lang/python-2.4 and only needed with
  (And, since Python 2.3, Optik is now part of the Python standard
library, under the name optparse)


  Best regards,

[1] http://optik.sourceforge.net/



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.8)

iEYEARECAAYFAkq27igACgkQdIssYB9vBoN8UwCfQ2caUrRUX6bt2+Rd5M33QGhB
tAQAnjYYSvW57CxTkj8ePlfGs8Tl5ZOF
=O627
-END PGP SIGNATURE-



[gentoo-dev] Last rites: dev-python/glewpy and dev-python/pycrash

2009-05-23 Thread Jesus Rivero

Hello everyone,

   dev-python/pycrash and dev-python/glewpy are either dead or 
unmaintained so im masking them for removal in 30 days. There are some 
non-fixable bugs regarding this packages. (see bug #198330 for glewpy 
and #221267 for pycrash)



   Best regards,

   Jesus Rivero (Neurogeek)
   Gentoo Python Team




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Ideas for a (fast) EAPI=3

2009-03-08 Thread Jesus Rivero

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Tiziano Müller wrote:
| Hi everyone
|
| With eapis 1 and 2 we introduced nice features but also a couple of new
| problems. One of them are the use dependencies when the package you
| depend on doesn't have the use flag anymore (see [1] for an example).
Hello all,

~Now that this topic was brought to light, I would like to add 
another point...


~I'm not sure if this has been worked out, or I just don't know how 
it is done, but a lot of python packages
~need to check use flags for dev-lang/python, like tk or threads for 
example. Now this is tricky considering the slotting of

~the interpreter. Let me give you an example:

~Suppose I have both python-2.5 and python-2.6 installed. python-2.5 
was installed with tk use flag enabled but python-2.6 has it disabled.
~When some package tries to check for foo? ( dev-lang/python[tk] ) 
it will merge nicely because the use dep restriction is achieved with 
python-2.5, even
~if python-2.6 is the selected interpreter and it misses the tk use 
flag. Is there a way to workaround this? am I missing something? or is 
just something else

~to take into account for next eapi?


~Thanks a lot,

~Best regards,

~Jesus Rivero (Neurogeek)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmz/lMACgkQdIssYB9vBoPEbwCfYg/BaEhRtNCv1LChbqdAt8RW
T8oAmwaA6Jz2HX5NbSHhD3XeN7JnqAHL
=oJr/
-END PGP SIGNATURE-




[gentoo-dev] dev-lang/python-2.6* unmask

2009-02-28 Thread Jesus Rivero

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello guys,

~ As some of you may know, Python-2.6 was launched on Oct 1st,  2008 
and have been sitting in the tree since Oct 5th. That is the official 
production version of the Python programming language. That means, 
python-2.5 is, according to the Python Project, officially old.


~  However, 2.6 version in the tree has been masked because some 
packages are affected by some minor changes in the language. We added a 
tracker bug [0] to keep maintainers informed of bugs/errors in their 
packages regarding the transition from 2.5 to 2.6.  This tracker was 
opened on June 30th 2008 and still has opened bugs.


~   The Python team has lay off a plan to unmask Python-2.6 in a 
month. In order to do so, we ask for your collaboration on fixing the 
bugs still opened in that tracker so we can unmask it safely. The 
majority of the bugs listed in there are relatively easy to fix and if 
you don't have the time to do it, please, don't hesitate to ask for our 
help, we'll be glad to give you a hand closing some of them (we just 
need a clear from the team or dev to do so)


~   Although those opened bugs are blocking the tracker already, 
I'll provide you with a compiled list so you don't even have to open a 
browser or open a shell to run bugz ;).


~   KDE Team:
~http://bugs.gentoo.org/show_bug.cgi?id=239233 - [PATCH] 
kde-base/superkaramba-3.5.10 should support dev-lang/python:2.6
~http://bugs.gentoo.org/show_bug.cgi?id=253582 - [PATCH] 
kde-base/dcoppython-3.5.10 fails with python-2.6


~Java Team:
~http://bugs.gentoo.org/show_bug.cgi?id=239479 - [PATCH] 
dev-java/javatoolkit fails with python-2.6
~http://bugs.gentoo.org/show_bug.cgi?id=246780 - 
dev-java/ant-core-1.7.1-r2 fails to build with dev-lang/python:2.6


~CJK Team:
~http://bugs.gentoo.org/show_bug.cgi?id=255210 - 
app-i18n/skim-1.4.5-r2 build fails with Python 2.6


~ SCI Team:
~http://bugs.gentoo.org/show_bug.cgi?id=258219 - 
dev-python/numpy-1.2.1 - selftest bugs though required for python-2.6 
compatibility


~Caster:
~http://bugs.gentoo.org/show_bug.cgi?id=243802 - 
app-office/taskcoach calls object.__init__ with arguments, which fails 
in python-2.6


~ Lack:
~ http://bugs.gentoo.org/show_bug.cgi?id=246786 - 
Version bump: dev-python/gdata-1.2.4


~  Proaudio:
~ http://bugs.gentoo.org/show_bug.cgi?id=251003 - 
[PATCH] media-libs/aubio-0.3.2-r1 not compatible with dev-lang/python-2.6


~  Matsuu:
~ http://bugs.gentoo.org/show_bug.cgi?id=258364 - 
sys-devel/distcc-3.1{,-r1} explictly compiles with python-2.5 even with 
python-2.6 selected


~ Thanks a lot for your help, we'll be waiting to hear from you.

~ Best regards,

[0] http://bugs.gentoo.org/show_bug.cgi?id=230205 - [TRACKER] Python-2.6 
incompatible packages



Jesus Rivero (Neurogeek)
Gentoo Python Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmqOmgACgkQdIssYB9vBoNryQCeICf6jUcfVdlhNEHRlKdPrK/d
VO8AnjCRDgbO/9zWw+Z2vBWt7egyrAYb
=8Xvr
-END PGP SIGNATURE-




Re: [gentoo-dev] PR Project Activity Issues

2009-01-26 Thread Jesus Rivero

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

AllenJB wrote:
| Hi all,
|
| My idea for a web-only setup would require more initial work, but I 
think would make maintenance much easier once set up. The Gentoo 
Newsletter would become a separate website, not based on GuideXML, but 
on a standard CMS. Instead of having set release dates (weekly or 
monthly), articles would just be released as soon as they are produced.

|
+1

~  I really like this idea. This could also add more dynamism to the 
Gentoo Project from the end-user's  point of view. Count me in if you 
need help setting things up!.

|
| AllenJB
|
| PS. This did start out as a submission for a council meeting agenda 
item, but I couldn't stop writing.

|
| PPS. To preempt the obvious suggestion: I do intend to become a 
developer, I just don't feel I have the time to commit right now. 
That'll hopefully change in ~6 months once I've finished uni and have a job.

|

Jesús Rivero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl+dZgACgkQdIssYB9vBoNmfACfXgVgHyhLoHMfNNSD5OkXkJbx
tJ0An13BDjCKqBxirhCUsXIGPk3+nlsI
=ZBmJ
-END PGP SIGNATURE-




[gentoo-dev] Python expat USE flag

2008-12-27 Thread Jesus Rivero

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello everyone,

~A while ago there was a discussion about the new expat USE flag in 
dev-lang/python. The flag was first introduced by Vapier on December 08th.


~While having expat USE flag may be of great use for embedded 
systems or in bootstrapping/releasing phases, it is not so in both in 
Gentoo related projects and software in general. Vapier fixed this by 
making the USE flag +expat.


~Now, the issue is many people, me included, don't like that name 
for the USE flag for a variety of reasons one of them being that expat 
doesn't correlate directly with the use of xml in python provided that 
developers may choose another lib for handling xml other than that, like 
libxml2.


~I want to change the USE flag to something else if people don't 
like 'build' and make it 'minimal' or 'embedded' as Nirbheek suggested/ 
mailto:nirbheek.chau...@gmail.com//. /I think that  is more suitable 
to the problem at hand. I don't want to start a silly fuss over this, 
just that there are some version bumps I'd like to make, but I would 
like to have a consensus on this before I make the bumps.


~   What do you think?

Best regards,

~Jesus Rivero (Neurogeek)
~Gentoo Dev - Python team
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklW/y8ACgkQdIssYB9vBoNQIwCeKaA2sIVqaHDlo2YurhVm38HP
jMgAn14gRFK0sY3TxyR6UWLenSjOAiJX
=4ubF
-END PGP SIGNATURE-




[gentoo-dev] Last rites: dev-python/pyframer

2008-10-25 Thread Jesus Rivero

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

~ dev-python/pyframer is now pretty old and unmaintained, therefore 
it is scheduled to be removed from the tree in 30 days.


See bug #239978 for additional info

Best regards,

Jesus Rivero (Neurogeek)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkEAz4ACgkQdIssYB9vBoN2kwCfbiHUggEaAErtYueTih/owlhu
wlgAnAgicP9oClSIJeA5rnjqc9x67YYC
=xyL3
-END PGP SIGNATURE-




Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins

2008-08-13 Thread Jesus Rivero

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robin H. Johnson wrote:

| If you would like to have the new bot in your #gentoo-* channel, would
| each channel founder/leader please respond to this thread, stating the
| channel name, and that they are the contact for any problems/troubles.

Hello,

Please, #gentoo-ve

araujo and me are contacts for that channel.

Thanks a lot,
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkijkJkACgkQdIssYB9vBoOkqQCeOBAwMCpTwuS7z95vg05MYrHc
tEYAn37j4oBfa/ekAFZxx9jLJJ4Fx4Tc
=uU74
-END PGP SIGNATURE-




[gentoo-dev] Last rites: dev-python/twisted-{pair, xish, flow} and dev-python/twibber (Removal due 11 October 2008)

2008-08-11 Thread Jesus Rivero
The following packages have been masked for removal in 30 days. 

dev-python/twisted-xish
dev-python/twisted-pair
dev-python/twisted-flow

They are either unmaintained or deprecated and they force downgrade on
the newly stable dev-python/twisted*-8.1.0

dev-python/twibber is also unmaintained and depends on twisted-xish
that is to be removed. 

See bug #231675 for reference.

Best regards, 

Jesus Rivero