[gentoo-dev] Farewell Gentoo.
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
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
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
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
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
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
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).
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
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).
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] Added support for variable expansion in source command. wrt bug #490896
-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
-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
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
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
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
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)
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
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
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 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
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
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
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
# 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
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/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
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
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
# 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
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
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
+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
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
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
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
-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-
