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 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 > 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] RFC: remove ldap from desktop profiles use flags
On May 5, 2012 3:14 PM, "Markos Chandras" 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 > > 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] news item: changes to stages (make.conf and make.profile)
On Jul 23, 2012 9:43 PM, "Brian Dolbec" 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
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 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] Packages up for grabs due apache herd removal
On Tue, Nov 27, 2012 at 2:43 PM, Pacho Ramos 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] Some packages up for grabs
On Dec 1, 2012 5:01 AM, "Wolfram Schlich" 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] [Proposal] Eclass for nodejs modules
On Mon, Feb 29, 2016 at 7:00 PM, Michael Orlitzky 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
[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] Re: About unresolved bugs assigned to voip for ages
On Jan 3, 2013 6:54 AM, "Pacho Ramos" 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...
[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
Re: tl;dr: [gentoo-dev] Fw: reviewboard and its bugs
On Tue, Aug 19, 2014 at 9:37 PM, Alex Xu 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
Re: [gentoo-dev] Fw: reviewboard and its bugs
the >> author always had reservations with its addition. >> >> There is ofcourse the alternative; to write ebuilds to install these >> packages without npm involvement. This would still require an >> eclass anyway. Either way, nodejs and java script are totally outside >> the realm of pythonic packages and are therefore outside my realm >> of knowledge and experience. Reviewboard developers have essentially >> created a huge dilemma for users of reviewboard in gentoo by going >> 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
[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-
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
Hi guys, On Sat, Apr 3, 2010 at 9:10 AM, Ben de Groot wrote: > On 3 April 2010 13:33, Richard Freeman 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 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 > - 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
Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force
On Sat, Apr 3, 2010 at 6:27 PM, Sebastian Pipping wrote: > On 04/04/10 00:30, Jesus Rivero (Neurogeek) wrote: >> Sebastian, count me in. > > Cool! > > >> 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. > > Can you elaborate on that? I'm not sure what what you refer to. > Yep. Take for instance this issue of GMN [1], here you can find some bugzie statistics like bugs assigned to teams/devs, bugs resolutions and other cool things. > > > Sebastian > > [1] http://www.gentoo.org/news/en/gmn/20080121-newsletter.xml#bugs-stats -- Jesus Rivero (Neurogeek) 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." 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)
[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 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] On hosting self-produced distfiles
Hi all, On Wed, Jan 19, 2011 at 7:50 PM, Diego Elio Pettenò wrote: > Hi all, > > I just wanted to write here a clarification regarding self-produced > distfiles, such as patchset tarballs, SCM snapshots and the like. Some > people seem under the impression that the correct way to host these is > to use mirror://gentoo/ and copy them on /space/distfiles-local on > dev.g.o. Please don't do this. > > If you produced the file yourself, and it doesn't matter if the file is > reproducible (unless it is reproducible to sha512 identity), please use > the public_html directory in your dev.gentoo.org home to host these. > This makes sure that the file won't be deleted from all its sources if > the ebuild is removed (or more likely replaced) from tree. Ask the Emacs > team how "easy" has been to recover gentoo-syntax files before. So, after all that, I'm not really clear if we are enforcing this, or not. A have a patchset. I put it in my devspace as suggested here. Is this right or should I still use the mirror://gentoo as the devmanual suggests? Thanks, -- Jesus Rivero (Neurogeek) Gentoo Developer
Re: [gentoo-dev] Reviving webapp-config
On Fri, Jun 10, 2011 at 7:49 AM, Sebastian Pipping 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
Re: [gentoo-dev] The Python problem
On Mon, Jun 27, 2011 at 7:58 AM, Dirkjan Ochtman 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] Packages up for grabs due truedfx retirement
On Wed, Jul 20, 2011 at 12:34 PM, 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 > 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 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 (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] Packages up for grabs due dragonheart retirement
On Wed, Jul 20, 2011 at 11:08 AM, Pacho Ramos 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 : > 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
[gentoo-dev] Last rites for app-accessibility/speakup-utils
# Jesus Rivero (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 cbrannon retirement
On Tue, Sep 13, 2011 at 3:24 PM, Pacho Ramos 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 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
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On Fri, Oct 14, 2011 at 9:54 PM, Mike Gilbert 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
2011/11/11 Tomáš Chvátal : > 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] 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.
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.
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 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
