Re: [gentoo-dev] rfc: calling all eclass phase functions by default
18.08.2014 16:56, hasufell пишет: hasufell: Even more interesting... you can work around this by inheriting base.eclass explicitly before e.g. unpacker.eclass, something like inherit base unpacker games = unpacker_src_unpack() is carried out by default (and the ebuild breaks if someone thinks the base.eclass is useless and removes it) inherit unpacker games = unpacker_src_unpack is not carried out by default although games.eclass does not directly overwrite it If you think any of this is sensible... Almost forgot, of course this does not work if you expect unpacker_src_unpacker() to run: inherit unpacker games base as well as inherit unpacker base games however inherit games unpacker base will work. And now... guess why the games herd made it a policy to always inherit games.eclass last. Because of the unpredictability of eclasses and that they may randomly add exported phase functions. It's a bit paranoid, but understandable, since we don't have any real rules here. So in the end 3 eclasses all tell you inherit me last! really!. Good luck with figuring out how to make a gnome game with python and multilib support work together. I can predict the days such a review would take in #gentoo-sunrise. Not less than 3. As i said early - always override necessary functions if you want non-default behaviour. Proposed solution with variable just add syntax sugar, doing the same thing. As for you as sunrise reviewer. I am member of proxy maintainers, i am also reviewing ebuilds from users. And they usually understands inherit logic very well, even in non-trivial cases. So, your expirience just differs with mine, not more, not less. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
19.08.2014 00:23, hasufell пишет:
Chris Reffett:
On August 18, 2014 11:11:56 AM EDT, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-08-18, o godz. 09:22:46
Chris Reffett creff...@gentoo.org napisał(a):
On 8/18/2014 8:56 AM, hasufell wrote:
Almost forgot, of course this does not work if you expect
unpacker_src_unpacker() to run:
inherit unpacker games base
as well as
inherit unpacker base games
however
inherit games unpacker base
will work.
And now... guess why the games herd made it a policy to always
inherit
games.eclass last. Because of the unpredictability of eclasses and
that
they may randomly add exported phase functions. It's a bit
paranoid, but
understandable, since we don't have any real rules here.
So in the end 3 eclasses all tell you inherit me last! really!.
Good
luck with figuring out how to make a gnome game with python and
multilib
support work together. I can predict the days such a review would
take
in #gentoo-sunrise. Not less than 3.
Would it be feasible to add a repoman check for situations like this,
where the behavior of a phase is dependent on inherit order? If so,
it
seems reasonable to me to require explicit calls to eclass functions
in
these cases to make it clear what's being called when.
Right now, we have no kind of repoman for eclasses. If you have time to
work on such a thing, please do. Otherwise, all we can do is put more
checks in ebuilds but that triggers the warning for the wrong people...
I was thinking more ebuild-side. Example: my ebuild inherits both
cmake-utils and games eclasses, and I don't explicitly define src_compile,
repoman full could pop up a warning like src_compile is ambiguous between
cmake-utils_src_compile and games_src_compile, please explicitly define this
phase and call the appropriate eclass function. I imagine that this would
pop up a lot of warnings, but I feel like it would improve readability and
make it explicit what should be going on where. I concede that it could make
a lot more boilerplate code in ebuilds, so that's a potential issue, mostly
just throwing out an idea here.
Chris Reffett
I don't want to code against warning tools, but against a reliable API.
That said, EXPORT_FUNCTIONS in eclasses should be definite and
non-recursive. Currently, people have to track down the actual exported
functions themselves through the endless list of indirect inheritance
which may:
* randomly change
* be highly dependant on the inherit order in the eclass and of those
indirectly inheriting others...
So to pick up the proposal again, I think this could make sense:
* disable exported functions from indirectly inherited eclasses
* have eclass authors do these things explicitly, so they have to export
ALL functions themselves and may have to adjust their eclasses, as in:
games_src_prepare() { base_src_prepare ; } (I know that base.eclass is
deprecated, this is an example)
* include the exported functions automatically in the generated eclass
manpages
That's proposal make more sense. Even if it will bring such short and
wrapper functions, it may be more compliant and ease things for PM itself.
Usually i do not agree with your proposals, but that's one in it's
current definition is really get +1 from me!
--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: dev-python/amara
On Sun, Aug 10, 2014 at 2:43 PM, Tiziano Müller dev-z...@gentoo.org wrote: # Tiziano Müller dev-z...@gentoo.org (10 Aug 2014) # Bundles an old (2.0.0) and vulnerable, but modified version of expat. # Testsuite is completely broken and upstream seems to be working on the # next rewrite instead of fixing this one. Nothing in the tree depends on it. # Removal in a month. dev-python/amara This mask is now gone. What happened? Cheers, Dirkjan
Re: [gentoo-dev] Followup notes: {cvs,git,git.overlays}.gentoo.org migration; awol: some overlays commits, gitweb
On 8/19/14 1:00 AM, Robin H. Johnson wrote: The new SSH keys, in case you still didn't have them: On Mon, Jun 30, 2014 at 10:26:52PM +, Robin H. Johnson wrote: 1024 5f:c3:fe:9a:ac:a7:99:f4:d3:c1:93:4c:52:87:74:28 (DSA) 256 aa:6a:e4:74:1d:73:d2:5a:9f:45:9f:18:55:81:c9:9a (ECDSA) 256 1c:2e:99:7d:c7:f0:bc:3b:a9:fb:d0:3e:2c:2a:79:ba (ED25519) 2048 24:3b:2d:3b:47:ca:7e:62:48:97:49:6a:f5:ad:66:88 (RSA) I noticed the ssh host key for cvs.gentoo.org changed just now. IMHO such announcement would greatly benefit from a digital signature. Just in case, this is what ssh printed out for me (the new key matches the announcement): $ cvs up @@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@ The RSA host key for cvs.gentoo.org has changed, and the key for the corresponding IP address 148.251.78.52 is unknown. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is 24:3b:2d:3b:47:ca:7e:62:48:97:49:6a:f5:ad:66:88. Please contact your system administrator. Add correct host key in /home/ph/.ssh/known_hosts to get rid of this message. Offending RSA key in /home/ph/.ssh/known_hosts:15 RSA host key for cvs.gentoo.org has changed and you have requested strict checking. Host key verification failed. cvs [update aborted]: end of file from server (consult above messages if any) Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Followup notes: {cvs,git,git.overlays}.gentoo.org migration; awol: some overlays commits, gitweb
On Tue, Aug 19, 2014 at 6:10 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: I noticed the ssh host key for cvs.gentoo.org changed just now. IMHO such announcement would greatly benefit from a digital signature. Robin's July 1 announcement, which I easily found when I ran into the same warning yesterday night, did have a signature. Cheers, Dirkjan
Re: [gentoo-dev] cvs.gentoo.org, git.gentoo.org, *.overlays.gentoo.org migration timeline ssh keys
Btw, I've noticed git.overlays.gentoo.org moved to Hetzner. When I remember my expirience of work with Hetzner - I'm scary about Gentoo' infrastructure destiny. I had a conversation with CEO of my current DDoS-proof hoster and he expressed his desire to help interesting projects and asked about the necessary amount of sponsorship and it's terms (and conditions). So, can I ask you to provide some info about infra team hardware requirements (which amount needs to be sponsored) and if it is any sponsoring conditions that Gentoo Foundation can suggest to the sponsor (maybe some banner, or something like that)? Anyway, mainly I need the amount of hardware gentoo infra team requires to [strike]get rid of hetzner[/strike] meet their comfortable-work requirements? Then I can discuss it with hoster again and then bring together somebody from infra-team and hoster's CEO or CTO to discuss the terms themselves. -- Best regsrds, mva signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] cvs.gentoo.org, git.gentoo.org, *.overlays.gentoo.org migration timeline ssh keys
On 8/19/14, 8:18 PM, Vadim A. Misbakh-Soloviov wrote: Btw, I've noticed git.overlays.gentoo.org moved to Hetzner. When I remember my expirience of work with Hetzner - I'm scary about Gentoo' infrastructure destiny. We are directly sponsored by them with at least another machine and are happy with their services. I had a conversation with CEO of my current DDoS-proof hoster and he expressed his desire to help interesting projects and asked about the necessary amount of sponsorship and it's terms (and conditions). So, can I ask you to provide some info about infra team hardware requirements (which amount needs to be sponsored) and if it is any sponsoring conditions that Gentoo Foundation can suggest to the sponsor (maybe some banner, or something like that)? Kindly consult past messages sent to the gentoo-announce list on that topic. Anyway, mainly I need the amount of hardware gentoo infra team requires to [strike]get rid of hetzner[/strike] meet their comfortable-work requirements? Then I can discuss it with hoster again and then bring together somebody from infra-team and hoster's CEO or CTO to discuss the terms themselves. Mind you, we are not going to 'ditch' sponsors, or randomly move services around just to use your preferred hoster, even if you establish sponsorship contacts with them. Alex PS. Your signature has a typo. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Followup notes: {cvs,git,git.overlays}.gentoo.org migration; awol: some overlays commits, gitweb
Paweł Hajdan, Jr.: On 8/19/14 1:00 AM, Robin H. Johnson wrote: The new SSH keys, in case you still didn't have them: On Mon, Jun 30, 2014 at 10:26:52PM +, Robin H. Johnson wrote: 1024 5f:c3:fe:9a:ac:a7:99:f4:d3:c1:93:4c:52:87:74:28 (DSA) 256 aa:6a:e4:74:1d:73:d2:5a:9f:45:9f:18:55:81:c9:9a (ECDSA) 256 1c:2e:99:7d:c7:f0:bc:3b:a9:fb:d0:3e:2c:2a:79:ba (ED25519) 2048 24:3b:2d:3b:47:ca:7e:62:48:97:49:6a:f5:ad:66:88 (RSA) I noticed the ssh host key for cvs.gentoo.org changed just now. IMHO such announcement would greatly benefit from a digital signature. I'm not going to commit anything until this issue is resolved. Can we get _confirmed_ fingerprints?
Re: [gentoo-dev] Followup notes: {cvs,git,git.overlays}.gentoo.org migration; awol: some overlays commits, gitweb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/19/2014 10:46 PM, hasufell wrote: Paweł Hajdan, Jr.: On 8/19/14 1:00 AM, Robin H. Johnson wrote: The new SSH keys, in case you still didn't have them: On Mon, Jun 30, 2014 at 10:26:52PM +, Robin H. Johnson wrote: 1024 5f:c3:fe:9a:ac:a7:99:f4:d3:c1:93:4c:52:87:74:28 (DSA) 256 aa:6a:e4:74:1d:73:d2:5a:9f:45:9f:18:55:81:c9:9a (ECDSA) 256 1c:2e:99:7d:c7:f0:bc:3b:a9:fb:d0:3e:2c:2a:79:ba (ED25519) 2048 24:3b:2d:3b:47:ca:7e:62:48:97:49:6a:f5:ad:66:88 (RSA) I noticed the ssh host key for cvs.gentoo.org changed just now. IMHO such announcement would greatly benefit from a digital signature. I'm not going to commit anything until this issue is resolved. Can we get _confirmed_ fingerprints? The following fingerprint information was presented in Robin's email of 1 July titled [gentoo-dev] cvs.gentoo.org, git.gentoo.org, *.overlays.gentoo.org migration timeline ssh keys and properly OpenPGP Signed: 1024 5f:c3:fe:9a:ac:a7:99:f4:d3:c1:93:4c:52:87:74:28 (DSA) 256 aa:6a:e4:74:1d:73:d2:5a:9f:45:9f:18:55:81:c9:9a (ECDSA) 256 1c:2e:99:7d:c7:f0:bc:3b:a9:fb:d0:3e:2c:2a:79:ba (ED25519) 2048 24:3b:2d:3b:47:ca:7e:62:48:97:49:6a:f5:ad:66:88 (RSA) - -- Kristian Fiskerstrand Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJT87hMAAoJEPw7F94F4TaghKEQAJDCdvT2K/de+uhbdBkgScYQ YdBDUqgsCMQFZmCsGyhncmbf83ZAGy37IcN0Dk6x1jLm/VxDPfpkkxF3RivJAtcJ 4hT3UYGzo9c+3yLpevRgU+/RTVWG2yflNdVeXyeKmAB+OVjIKIio8j6pK5YuQjGT mit5jVsgb03pKPXHMdn2Fy/lgV69llhOVtpAE6mtpxi3qtPafB1o5KYx71ufT04q Axo2ucbbEKfY0ZQ6dQk9DtAzIJbgei9G5w0rNgayVXFwnQ5xGcqdZDqE3fjC9Vm5 iV/taJIg0Ks+L/mjl/rMg/6lcVGyy/Fv0nk5GK3mEpoUjoeoJkmZIxQScEy7g9k/ gfXyQEclbS3+05PqfE7AUvyC7j10mlc/I0KgNjOUwEqLv/LS/m2+fTKT9JjXi63u zfYF3jqAUvqeb4bnhTZVuCvYUyUP1ShyQnwPGXlVt1CLujf5nyf6hP++Ect9Fjd4 N8s4K7fT2FUPTczZGmB75XtXETgUWcfvtgT/kP2S5auDYerP0KoId0zf7R0d0Psm PupvEefpBm2wdRXsUJyH0ulDJhee0TIzfUQEVaOOpoyYj98rPilUC7Z7O+t7Ls46 RsBZVFmT/xJkDYeuE0A4wOX40H8exzHZ/BtumfFWY56g80GuWy/phYn5g7LGqUZm zVtfQ/23vUhwcxMF0Ha+ =2vHT -END PGP SIGNATURE-
Re: [gentoo-dev] Followup notes: {cvs,git,git.overlays}.gentoo.org migration; awol: some overlays commits, gitweb
Kristian Fiskerstrand: On 08/19/2014 10:46 PM, hasufell wrote: Paweł Hajdan, Jr.: On 8/19/14 1:00 AM, Robin H. Johnson wrote: The new SSH keys, in case you still didn't have them: On Mon, Jun 30, 2014 at 10:26:52PM +, Robin H. Johnson wrote: 1024 5f:c3:fe:9a:ac:a7:99:f4:d3:c1:93:4c:52:87:74:28 (DSA) 256 aa:6a:e4:74:1d:73:d2:5a:9f:45:9f:18:55:81:c9:9a (ECDSA) 256 1c:2e:99:7d:c7:f0:bc:3b:a9:fb:d0:3e:2c:2a:79:ba (ED25519) 2048 24:3b:2d:3b:47:ca:7e:62:48:97:49:6a:f5:ad:66:88 (RSA) I noticed the ssh host key for cvs.gentoo.org changed just now. IMHO such announcement would greatly benefit from a digital signature. I'm not going to commit anything until this issue is resolved. Can we get _confirmed_ fingerprints? The following fingerprint information was presented in Robin's email of 1 July titled [gentoo-dev] cvs.gentoo.org, git.gentoo.org, *.overlays.gentoo.org migration timeline ssh keys and properly OpenPGP Signed: 1024 5f:c3:fe:9a:ac:a7:99:f4:d3:c1:93:4c:52:87:74:28 (DSA) 256 aa:6a:e4:74:1d:73:d2:5a:9f:45:9f:18:55:81:c9:9a (ECDSA) 256 1c:2e:99:7d:c7:f0:bc:3b:a9:fb:d0:3e:2c:2a:79:ba (ED25519) 2048 24:3b:2d:3b:47:ca:7e:62:48:97:49:6a:f5:ad:66:88 (RSA) Thanks, I found it now. Maybe it would still be better to repost this close before it actually hits us to minimize confusion.
Re: [gentoo-dev] Followup notes: {cvs,git,git.overlays}.gentoo.org migration; awol: some overlays commits, gitweb
On Tue, 19 Aug 2014 21:19:11 + hasufell hasuf...@gentoo.org wrote: Thanks, I found it now. Maybe it would still be better to repost this close before it actually hits us to minimize confusion. Quoting from Robin's email From Monday, Aug. 18, 2014: Last evening, the old sponsor where cvs/git/git.overlays was hosted turned off the old servers, earlier than I expected. So, I'm sure there would have been an announcement again before the final switch. Had the actual date been known in advance. -- Brian Dolbec dolsen
[gentoo-dev] Fw: reviewboard and its bugs
Begin forwarded message: Date: Wed, 20 Aug 2014 08:45:21 +0800 From: IAN DELANEY idel...@gentoo.org To: gentoo-pyt...@lists.gentoo.org Subject: reviewboard and its bugs cancel the gentoo-python@lists, was intended for gentoo-dev@lists The package reviewboard has reached a stage of warranting this submission to the ML. A simple search of reviewboard in bugzilla lists a few 'user submitted' bugs and no less than 3 sec bugs. This package I added initially because interest was expressed mainly by my final mentor and the other (prior) co-maintainer. Because of changes to reviewboard upstream, we need a new eclass and category to cater to certain js packages. Now wishing to re-write all I have already written in the bugs, in summary, reviewboard has become unworkable by the developers of reviewboard itself going down the path of nodejs. Enter npm. npm was an unknown to me until Djblets and django-pipeline ebuilds failed due to the absence of UglifyJS and some related js deps. On being informed of ebuilds for this and related deps in the overlay of neurogeek, I discovered they required npm which it seems comes in nodejs. The response drawn by fellow devs over npm is in my limited experience unprecedented. The overall reaction was leave it and don't go there. What became apparent from the ebulds in neurogeek's overlay was that these deps didn't lend themselves well to writing ebuilds for them for portage. In the overlay there is in fact an npm eclass to overseer their installation into the system. After some somewhat reluctant discussion of npm in irc, it has at least been suggested that the use of nodejs' UglifyJS in django-pipeline could be patched out to relieve us all of any reliance or involvement of npm to install these js oriented deps. That has not ofcourse been attempted or tested and allows for the probability of breaking Djblets and or reviewboard which I suspect has been written by reviewboard developers to explicitly depend on and call these deps. The decision it seems isn't whether to allows npm into portage, it already comes with nodejs correct me if I misunderstand. The question is whether to support this npm installing packages into a gentoo system by ebuilds essentially outside of portage. This requires an eclass and it has been suggested a whole new category for portage under which to categorise these npm type packages. Such an eclass has already been written, however, that it has never been added to portage along with js style packages in the overlay, to me at least, strongly suggests 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
tl;dr: [gentoo-dev] Fw: reviewboard and its bugs
tl;dr: python package has nodejs dependencies, we don't have a mechanism like distutils.eclass to install those system-wide. signature.asc Description: OpenPGP digital signature
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
Re: [gentoo-dev] Fw: reviewboard and its bugs
FWIW, I suspect npm is here to stay, and it has a facility for installing system-wide utilities; and NodeJS is both usable and convenient for system-level scripting which has no connection to webapps, and has the ability to build native code that integrates with NodeJS code as well. IMO, it would be pretty insane to write packages that duplicate npm packages; support within portage for installing things with it makes more sense. I've occasionally toyed with the idea of a webapp that exposes packages in npm as ebuilds and generates the required metadata on the fly, so anything in the npm repository would simply *be* a Gentoo package. Not sure the idea is viable, but it might be. If that existed, and then some known-stable subset of packages for which system-wide installation is appropriate could be mirrored in the portage tree, that would probably be ideal. -Tim On Tue, Aug 19, 2014 at 8:48 PM, IAN DELANEY del...@iinet.com.au wrote: Begin forwarded message: Date: Wed, 20 Aug 2014 08:45:21 +0800 From: IAN DELANEY idel...@gentoo.org To: gentoo-pyt...@lists.gentoo.org Subject: reviewboard and its bugs cancel the gentoo-python@lists, was intended for gentoo-dev@lists The package reviewboard has reached a stage of warranting this submission to the ML. A simple search of reviewboard in bugzilla lists a few 'user submitted' bugs and no less than 3 sec bugs. This package I added initially because interest was expressed mainly by my final mentor and the other (prior) co-maintainer. Because of changes to reviewboard upstream, we need a new eclass and category to cater to certain js packages. Now wishing to re-write all I have already written in the bugs, in summary, reviewboard has become unworkable by the developers of reviewboard itself going down the path of nodejs. Enter npm. npm was an unknown to me until Djblets and django-pipeline ebuilds failed due to the absence of UglifyJS and some related js deps. On being informed of ebuilds for this and related deps in the overlay of neurogeek, I discovered they required npm which it seems comes in nodejs. The response drawn by fellow devs over npm is in my limited experience unprecedented. The overall reaction was leave it and don't go there. What became apparent from the ebulds in neurogeek's overlay was that these deps didn't lend themselves well to writing ebuilds for them for portage. In the overlay there is in fact an npm eclass to overseer their installation into the system. After some somewhat reluctant discussion of npm in irc, it has at least been suggested that the use of nodejs' UglifyJS in django-pipeline could be patched out to relieve us all of any reliance or involvement of npm to install these js oriented deps. That has not ofcourse been attempted or tested and allows for the probability of breaking Djblets and or reviewboard which I suspect has been written by reviewboard developers to explicitly depend on and call these deps. The decision it seems isn't whether to allows npm into portage, it already comes with nodejs correct me if I misunderstand. The question is whether to support this npm installing packages into a gentoo system by ebuilds essentially outside of portage. This requires an eclass and it has been suggested a whole new category for portage under which to categorise these npm type packages. Such an eclass has already been written, however, that it has never been added to portage along with js style packages in the overlay, to me at least, strongly suggests 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
