[gentoo-dev] Re: Mailing list moderation and community openness

2018-03-21 Thread Duncan
Alec Warner posted on Wed, 21 Mar 2018 10:44:48 -0400 as excerpted:

> On Wed, Mar 21, 2018 at 1:36 AM, Eray Aslan  wrote:
> 
>> On Tue, Mar 20, 2018 at 10:28:48AM -0500, Matthew Thode wrote:
>> > While I personally do no agree with mailing list moderation infra has
>> > been tasked with moving forward on it.
>>
>> You can always resign from infra.
>>
>>
>> That was a somewhat tongue-in-cheek comment but not wholly.  You cant
>> cop out by saying it was an order from council.  I understand if you
>> dont but do consider it.  Fight the good fight.
>>
>>
> So when there is conflict its pretty often that you have 3 options.
> 
> 1) Accept 2) Leave 3) Escalate

Wise words.

Here the context was/is infra, but they apply to general devs and users 
who disagree with this as well, thus my own personal interest, altho I'm 
not so much a "disagree" as a "concerned and sad it has to come to this", 
as I see both sides.

[Note:  I intend this to be my only post to this thread, unless a reply 
calls for further reply on my part.  It's my position of record on the 
moderation/whitelisting and may also be my last to the list before it 
goes moderated.  If that's not of interest to you I'd rather you skip the 
rest of the post and use the time for something you consider more 
constructive.  =:^) ]

> I'm not sure 3 is possible (the council is already the highest body). I
> also think that as a organization this is how we arranged it to be.

Astute observation.

> Speaking for myself, this is not the worst issue I've seen in Gentoo and
> so I thing doing 2 is probably not very effective. Its also likely I can
> only do 2 once (because maybe I would not be welcome'd back or want to
> contribute anymore.)

Also astute.

I'm ignoring my urge to point to "real world" examples as this list is 
*definitely* not the place, but in the safer general realm it can simply 
be observed that there's /always/ a leave/stay-and-accept (if only 
temporarily/strategically) argument to be made, even in the /worst/ cases 
(which must here be left to imagination and history) where arguably 
"leave" is the only morally acceptable alternative.

Fortunately, I believe most will agree this isn't a "worst" case in that 
regard, tho it may be bad enough that some find they must leave.

But for both users and devs there remain the practical questions:

Where else would I go?  Is that alternative actually practically viable?  
Would I be more effective there than here, hoping to eventually reverse 
the decision (or for those like me more on the sad-it-came-to-this-but-I-
see-why-some-believe-it-has side, hoping a short trial is demonstration 
enough of capacity and that it lowers the threat to where even those that 
agree it has to come to that now feel comfortable in reverting it, tho 
possibly retaining the capacity to reimpliment if necessary)?

In practice, there are certainly from-source alternatives.  However, 
again practically, gentoo does seem to be the biggest, and most others 
seem to either be mostly-compatible offshoots such as funtoo and exherbo 
that to some degree still depend on the larger gentoo tree and community, 
or to make choices that put them to one side or the other of gentoo's 
"automated/scripted from-source" approach (arch's core-binary approach on 
the toward-binaries side, and lfs/linux-from-scratch's much more manual-
but-still-guided, approach on the other).

There's also the very practical "but I already know and am familiar with 
gentoo and how it works (both technically and socially) and would have to 
learn the others" factor.

For both those reasons and I suppose others, gentooers who have been 
around a few years, at least long enough to develop that familiarity, 
tend to stay around as long as they remain interested in gentoo's general 
automated-from-source approach (tho many ultimately lose that interest 
and go binary-distro or leave the FLOSS community entirely), unless of 
course forced out as incompatible with continuing community interest, in 
which case, given little choice, they often land at one of those 
alternatives.

> That leaves 1 and one interests me for many reasons.
> 
> a) as noted earlier, decisions are not set in stone. Its possible we
> could turn on this whitelisting solution for a brief period and the
> decision is overturned at the next council meeting, or perhaps at the
> next council election once the existing council is replaced.

Agreed.  I've already mentioned what I believe would be my ideal outcome, 
above.  Try the whitelisting as proposed for awhile, then having 
demonstrated the capacity/threat, relax things, while maintaining the 
capacity, such that hopefully the toxic people that created the initial 
need will not find it worth their while to be toxic here once again, but 
with the capacity to reinstitute should they do so.

(Yes, I know that unused tools fall into disrepair over time, but often, 
repair, or even redo if necessary, is easier the second time 

Re: [gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)

2018-03-21 Thread Manuel Rüger
On 22.03.2018 01:25, Zac Medico wrote:
> On 03/19/2018 09:49 PM, Manuel Rüger wrote:
>> Hi Zac,
>>
>> alternatively could --exclude be extended to support sets?
>> So users could --exclude @world or @profile.
> 
> Your idea doesn't really fit the current meaning of --exclude, since
> --exclude excludes packages from being merged, but still adds installed
> instances to the dependency graph in order to ensure that their
> dependencies remain satisfied.
> 
Thanks for providing the clarification, now I have a better
understanding what both approaches do and withdraw my suggestion for
this patch. :-)

> I'd question the usefulness of a finer-grained approach that you're
> suggesting. I don't foresee people wanting to fiddle around with which
> package sets they want to ignore, and I wouldn't encourage them to do so.
> 
> The intention of the --ignore-world option is to say, "I only care about
> the packages that I'm specifying in the emerge arguments, do anything
> necessary to install them." In this sort of situation, I think a person
> generally wants to ignore everything except the given packages and their
> dependencies, because they don't want to do a bunch of fiddling to
> figure out which sets they'd need to exclude in order to avoid
> conflicts. If they want to fiddle with something, they are free to
> adjust their package set configuration, so why wouldn't they?
> 
> Anyway, I'm not necessarily opposed to adding a finer grained
> --ignore-set option. However, it would be more work, it would be more
> complex, and I wouldn't advise anyone to use it.
> 
> If people want to automate something in a disposable system, or they're
> in a position to use --ask and check the result for sanity, then I think
> --ignore-world is a good solution.
> 
> If people want something that's safe to use on a production system, then
> I'll advise them to manually adjust their package set configuration.
> 



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread M. J. Everitt
On 22/03/18 00:33, Kristian Fiskerstrand wrote:
> 
> Most contributions should happen via patches on b.g.o
>
Who was lamenting about the every-increasing bug queue on this Very list
recently?

And what about those 5+ year old bugs that are rotting for packages long
last-rited from the tree ?



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)

2018-03-21 Thread Zac Medico
On 03/21/2018 04:53 PM, Joakim Tjernlund wrote:
> On Tue, 2018-03-20 at 05:49 +0100, Manuel Rüger wrote:
>> Hi Zac,
>>
>> alternatively could --exclude be extended to support sets?
>> So users could --exclude @world or @profile.
> 
> Yes please, I think I have a bug in that direction already(and --exclude 
> during --depclean)

Bug 634092 specified -C which is a synonym for --unmerge, so you need to
decide which one it is. The --unmerge code doesn't deal with
dependencies, so it's an entirely separate feature. You're "emerge -e
@world --exclude @system" suggestion would be another entirely separate
feature, you need to file separate bugs for each one.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Kristian Fiskerstrand
On 03/22/2018 12:56 AM, Chí-Thanh Christopher Nguyễn wrote:
> Rich Freeman schrieb:
> 
>> Actually, I think it is more of a technical constraint.  It is
>> basically impossible to blacklist somebody on a mailing list, since
>> all they need to do is roll up a new email address.
>>
>> I can think of various arguments for whitelisting or not whitelisting,
>> but it seems silly to blacklist.
> 
> And how often did it actually happen that blacklisting was evaded on -dev
> mailing list?

we are aware of at least one case of evasion like this within the
relatively near past, but it is more a matter of principle as we don't
know if there are sock-puppets etc around.

The main things is really, the bar for whiltelisting is very low, you
just need a current dev to vouch for you, which is similiar to editbugs
and the #-dev channel on IRC. Most discussion should anyways happen on
-project ML, whereby the -dev ML is technical in nature. So there isn't
any real restriction being imposed here.

Most contributions should happen via patches on b.g.o

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Kristian Fiskerstrand
On 03/22/2018 12:56 AM, Chí-Thanh Christopher Nguyễn wrote:
> Michael Palimaka schrieb:
>> I see that in bug #650964[1] Council is pushing forward again with
>> implementing user whitelisting on this mailing list (ie. anyone that is
>> not "approved" will have their mail rejected).
>>
>> Could someone please explain how this doesn't directly contradict the
>> core tenets of an open and inclusive community?
> 
> (I do not intend to single out your post, just replying to the thread in
> general here)
> 
> I would like to ask people to stay respectful in their disagreement towards
> the Council and their decision here. You might not agree with the decision,
> but the Council is an elected body and was given these powers by the
> developer community which they represent. Also I have no doubt that Council
> members who voted for -dev moderation are aware of the counter arguments and
> honestly expect a net positive effect from this.
> 
> If you dislike mailing list moderation, campaign and/or vote in the next
> period for candidates who want to reverse this decision.

+1 for this, and also note that the whitelisting approach allows for
those opposing to start a project for -dev ML moderation that is similar
to editbugs and proxy maintenance as we currently have in the project.


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)

2018-03-21 Thread Zac Medico
On 03/19/2018 09:49 PM, Manuel Rüger wrote:
> Hi Zac,
> 
> alternatively could --exclude be extended to support sets?
> So users could --exclude @world or @profile.

Your idea doesn't really fit the current meaning of --exclude, since
--exclude excludes packages from being merged, but still adds installed
instances to the dependency graph in order to ensure that their
dependencies remain satisfied.

I'd question the usefulness of a finer-grained approach that you're
suggesting. I don't foresee people wanting to fiddle around with which
package sets they want to ignore, and I wouldn't encourage them to do so.

The intention of the --ignore-world option is to say, "I only care about
the packages that I'm specifying in the emerge arguments, do anything
necessary to install them." In this sort of situation, I think a person
generally wants to ignore everything except the given packages and their
dependencies, because they don't want to do a bunch of fiddling to
figure out which sets they'd need to exclude in order to avoid
conflicts. If they want to fiddle with something, they are free to
adjust their package set configuration, so why wouldn't they?

Anyway, I'm not necessarily opposed to adding a finer grained
--ignore-set option. However, it would be more work, it would be more
complex, and I wouldn't advise anyone to use it.

If people want to automate something in a disposable system, or they're
in a position to use --ask and check the result for sanity, then I think
--ignore-world is a good solution.

If people want something that's safe to use on a production system, then
I'll advise them to manually adjust their package set configuration.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Kristian Fiskerstrand
On 03/22/2018 12:56 AM, Chí-Thanh Christopher Nguyễn wrote:
> Kristian Fiskerstrand schrieb:
> 
>> Switching to mailman might have some good merits on its own, but as I
>> understand it it isn't necessary for the proposal at hand, that can be
>> solved using access control lists in mlmmj-process?
> 
> I would advise caution that Council better not try to micro-manage Infra here.

By all means, infra should do what they think is right, but this
particular decision doesn't force infra to switch mailing list
infrastructure. If they believe there are reasons to do so, by all
means, but the decision doesn't result in

On 03/20/2018 04:28 PM, Matthew Thode wrote:
> There are still some issues with it infra side (archiving will still
> have to use the old system) and moving mailing lists is going to be fun,
> but them the breaks.


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Chí-Thanh Christopher Nguyễn
Rich Freeman schrieb:

> Actually, I think it is more of a technical constraint.  It is
> basically impossible to blacklist somebody on a mailing list, since
> all they need to do is roll up a new email address.
> 
> I can think of various arguments for whitelisting or not whitelisting,
> but it seems silly to blacklist.

And how often did it actually happen that blacklisting was evaded on -dev
mailing list?


Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Chí-Thanh Christopher Nguyễn
Michael Palimaka schrieb:
> I see that in bug #650964[1] Council is pushing forward again with
> implementing user whitelisting on this mailing list (ie. anyone that is
> not "approved" will have their mail rejected).
> 
> Could someone please explain how this doesn't directly contradict the
> core tenets of an open and inclusive community?

(I do not intend to single out your post, just replying to the thread in
general here)

I would like to ask people to stay respectful in their disagreement towards
the Council and their decision here. You might not agree with the decision,
but the Council is an elected body and was given these powers by the
developer community which they represent. Also I have no doubt that Council
members who voted for -dev moderation are aware of the counter arguments and
honestly expect a net positive effect from this.

If you dislike mailing list moderation, campaign and/or vote in the next
period for candidates who want to reverse this decision.


Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Chí-Thanh Christopher Nguyễn
Kristian Fiskerstrand schrieb:

> Switching to mailman might have some good merits on its own, but as I
> understand it it isn't necessary for the proposal at hand, that can be
> solved using access control lists in mlmmj-process?

I would advise caution that Council better not try to micro-manage Infra here.


Best regards,
Chí-Thanh Christopher Nguyễn



[gentoo-dev] New category: app-metrics

2018-03-21 Thread Manuel Rüger
Hi everyone,

I'm planning to add a new category app-metrics, which is mainly (at
least for my own use case) going to be used for prometheus[0] and its
exporters providing endpoints for prometheus. It can be used for other
packages whose _main_ purpose is to provide metrics, transform or
consume them.

* net-analyzer/prometheus
* app-admin/bind_exporter
* app-admin/elasticsearch_exporter
* app-admin/mongodb_exporter
* app-admin/nginx-vts-exporter
* app-admin/prom2json
* dev-util/buildbot-prometheus

In addition, the following packages will drop their prometheus- prefix
during the package move:

* net-analyzer/prometheus-blackbox_exporter
* net-analyzer/prometheus-node_exporter
* net-analyzer/prometheus-redis_exporter
* net-analyzer/prometheus-snmp_exporter
* net-analyzer/prometheus-uwsgi_exporter
* net-analyzer/prometheus-pushgateway
* net-analyzer/prometheus-alertmanager

With the growing adoption of prometheus I expect more exporters to be
added (I have five more that I want to add in the near future).


Thanks,

Manuel

[0] https://prometheus.io




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)

2018-03-21 Thread Joakim Tjernlund
On Tue, 2018-03-20 at 05:49 +0100, Manuel Rüger wrote:
> Hi Zac,
> 
> alternatively could --exclude be extended to support sets?
> So users could --exclude @world or @profile.

Yes please, I think I have a bug in that direction already(and --exclude during 
--depclean)


> 
> Cheers,
> Manuel
> 
> On 22.03.2018 00:03, Zac Medico wrote:
> > Ignore the @world package set and its dependencies. This may be useful
> > if there is a desire to perform an action even though it might break
> > the dependencies of some installed packages (it might also remove
> > installed packages in order to solve blockers). This also alters the
> > behavior of --complete-graph options so that only deep dependencies
> > of packages given as arguments are included in the dependency graph.
> > This option may be useful as an alternative to --nodeps in cases where
> > it is desirable to account for dependencies of packages given as
> > arguments.
> > 
> > Bug: https://bugs.gentoo.org/608564
> > ---
> >  man/emerge.1  | 17 +
> >  pym/_emerge/create_depgraph_params.py |  4 
> >  pym/_emerge/depgraph.py   |  8 ++--
> >  pym/_emerge/main.py   |  9 +
> >  pym/portage/tests/resolver/test_complete_graph.py | 18 ++
> >  5 files changed, 54 insertions(+), 2 deletions(-)
> > 
> > diff --git a/man/emerge.1 b/man/emerge.1
> > index a17b65ed2..01ce62e51 100644
> > --- a/man/emerge.1
> > +++ b/man/emerge.1
> > @@ -630,6 +630,23 @@ Therefore, \fB\-\-usepkgonly\fR (or 
> > \fB\-\-getbinpkgonly\fR) must be
> >  used in order to enable soname depedency resolution when installing
> >  packages.
> >  .TP
> > +.BR "\-\-ignore\-world [ y | n ]"
> > +Ignore the @world package set and its dependencies. This may be useful
> > +if there is a desire to perform an action even though it might break
> > +the dependencies of some installed packages (it might also remove
> > +installed packages in order to solve blockers). This also alters the
> > +behavior of \fB\-\-complete\-graph\fR options so that only deep
> > +dependencies of packages given as arguments are included in the
> > +dependency graph. This option may be useful as an alternative to
> > +\fB\-\-nodeps\fR in cases where it is desirable to account for
> > +dependencies of packages given as arguments.
> > +
> > +\fBWARNING:\fR
> > +This option is intended to be used only with great caution, since it is
> > +possible for it to make nonsensical changes which may lead to system
> > +breakage. Therefore, it is advisable to use \fB\-\-ask\fR together with
> > +this option.
> > +.TP
> >  .BR \-j\ [JOBS] ", "  \-\-jobs[=JOBS]
> >  Specifies the number of packages to build simultaneously. If this option is
> >  given without an argument, emerge will not limit the number of jobs that 
> > can
> > diff --git a/pym/_emerge/create_depgraph_params.py 
> > b/pym/_emerge/create_depgraph_params.py
> > index fc7fa60d7..0405011fd 100644
> > --- a/pym/_emerge/create_depgraph_params.py
> > +++ b/pym/_emerge/create_depgraph_params.py
> > @@ -26,6 +26,7 @@ def create_depgraph_params(myopts, myaction):
> >   # ignore_soname_deps: ignore the soname dependencies of built
> >   #   packages, so that they do not trigger dependency resolution
> >   #   failures, or cause packages to be rebuilt or replaced.
> > + # ignore_world: ignore the @world package set and its dependencies
> >   # with_test_deps: pull in test deps for packages matched by arguments
> >   # changed_deps: rebuild installed packages with outdated deps
> >   # changed_deps_report: report installed packages with outdated deps
> > @@ -56,6 +57,9 @@ def create_depgraph_params(myopts, myaction):
> >   myparams["selective"] = True
> >   return myparams
> >  
> > + if myopts.get('--ignore-world') is True:
> > + myparams['ignore_world'] = True
> > +
> >   rebuild_if_new_slot = myopts.get('--rebuild-if-new-slot')
> >   if rebuild_if_new_slot is not None:
> >   myparams['rebuild_if_new_slot'] = rebuild_if_new_slot
> > diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
> > index 6c728684f..f7ea27c37 100644
> > --- a/pym/_emerge/depgraph.py
> > +++ b/pym/_emerge/depgraph.py
> > @@ -163,7 +163,10 @@ class _frozen_depgraph_config(object):
> >   self.trees[myroot]["bintree"] = DummyTree(
> >   
> > DbapiProvidesIndex(trees[myroot]["bintree"].dbapi))
> >  
> > - self._required_set_names = set(["world"])
> > + if params.get("ignore_world", False):
> > + self._required_set_names = set()
> > + else:
> > + self._required_set_names = set(["world"])
> >  
> >   atoms = ' '.join(myopts.get("--exclude", [])).split()
> >   self.excluded_pkgs = _wildcard_set(atoms)
> > @@ -7554,6 

Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Gregory Woodbury
John Levine, author of "The Internet For Dummies," once set up a robo-moderation
process for the Usenet newsgroup soc.religion.unitarian-univ
(Unitarian Universalists).
The group, along with most of Usenet, ultimately "died" due to lack of
attention from
the moderators, who failed to curb one of their own.

However, the robo-moderator worked quite well, and still is
technically in-place. The
first post by a person generated an email to the poster to verify the
email addres,
and required the poster to reply with a confirmation. The posts then
went through
without anyone having to approve or whilelist things.  If a poster subsequently
became a "problem" their postings could be placed in a moderation
required status,
and some human would evelute the posts and handle the quelling of off-topic or
flame generating posts. In extreme cases, posters could be banned for
varying periods
of time.

The programs where quite powerful, and amazingly simple and elegant to implent.
The source is available, and should be easily adapted for practically
any system with
bash shell hook capabilities. The infra team might want to look at
that code and try
something like it.  Some addresses can be injected at setup time requiring human
action before posts are approved (Rejected posts would be sent back to the perp
requesting re-writing or abandoning.

The moderators did not have to login anywhere to work with the bot,
all interactions
were done via email.  The system is/was quite nice, and my mangled memories
should not be the deciding factors when looking at it.

Such a system might well serve as a means of allowing fully free entry into the
list, while still providing the ability to control things if it gets
out of hand.

On Wed, Mar 21, 2018 at 1:19 PM, Rich Freeman  wrote:
> On Wed, Mar 21, 2018 at 12:55 PM, R0b0t1  wrote:
>>
>> I can't tell, and I suspect other people can't either.
>>
>
> This is the crux of the issue.  Decisions involving people issues are
> made behind closed doors, which means that others are not free to
> confirm for themselves whether those actions are correct.  This tends
> to lead to ongoing debate over whether those decisions were
> appropriate, with everybody arguing from their own knowledge, and the
> only ones who know the information used to make the decision are
> barred from talking about it.  This is basically a debate where
> participation is limited to the ignorant, at least as far as the
> particular details go (the general principles are debated by all).
>
> That said, even if the decisions were made in the open I wouldn't
> expect all to agree with them.
>
> Ultimately though there are pros and cons to making these kinds of
> decisions in the open, and there is not universal agreement regarding
> how these situations ought to be handled.  We can either fight about
> it until the end of time, or we can agree on some way to determine
> what approach we are going to take and then support it (perhaps
> begrudgingly).  Right now the mechanism that we have in place is the
> Council.  The only other mechanism I could see that would make any
> sense would be a referendum on the issue.  That gets unwieldy if we
> try to apply it to every little decision, but maybe for the big
> picture issues it would make sense.
>
> However, I think a lot of people would be surprised at the outcome.
> We all assume that we're all here for the same reasons, but as I
> commented on my blog Gentoo is a bit unique among distros and many of
> us are here for very different reasons, and have different priorities.
> Also, there is sometimes a tendency to assume that all FOSS projects
> work the same way.  When I was listening to a talk about how one of
> the BSDs dealt with these kinds of issues I was shocked to discover
> that much of their dev communications happens on completely closed
> lists (not just closed to posting, but to reading as well).  Gentoo
> has the gentoo-core list but it is very low traffic and it tends to be
> used for things like swapping cell phone numbers before conferences.
> When anything substantive comes up there are usually several people
> who chime in to rightly point out that this talk belongs on a public
> list.
>
> Bottom line is that there are a lot of different ways projects can
> run, and they all have their pros and cons.  A lot of the FOSS we
> depend on actually gets built or discussed behind closed doors.  I
> doubt many of us want Gentoo to go that far, but I suspect there is a
> lot of interest in taking smaller steps in that general direction.
>
> --
> Rich
>



-- 
G.Wolfe Woodbury
redwo...@gmail.com



Re: [gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)

2018-03-21 Thread M. J. Everitt
On 21/03/18 23:26, M. J. Everitt wrote:
> n 20/03/18 04:49, Manuel Rüger wrote:
>> Hi Zac,
>>
>> alternatively could --exclude be extended to support sets?
>> So users could --exclude @world or @profile.
>>
>> Cheers,
>> Manuel
>>
> The idea is sound enough, but I fear the syntax would be too confusing.
>
> Reading a potential command-line as "emerge   world-file unless --no-replace specified>  puts my head into
> a spin! I can see it might be clearer for an unmerge perhaps ..
>
> Unless I'm missing something fundamental ...
>
On a related note, it would be quite handy to enumerate an
"exclude-from" option like rsync/tar(?) to specify a file with the
--exclude options in. There could be some way to append @world to this
option, perhaps?

MJE



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)

2018-03-21 Thread M. J. Everitt
n 20/03/18 04:49, Manuel Rüger wrote:
> Hi Zac,
>
> alternatively could --exclude be extended to support sets?
> So users could --exclude @world or @profile.
>
> Cheers,
> Manuel
>
The idea is sound enough, but I fear the syntax would be too confusing.

Reading a potential command-line as "emergeputs my head into
a spin! I can see it might be clearer for an unmerge perhaps ..

Unless I'm missing something fundamental ...



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)

2018-03-21 Thread Manuel Rüger
Hi Zac,

alternatively could --exclude be extended to support sets?
So users could --exclude @world or @profile.

Cheers,
Manuel

On 22.03.2018 00:03, Zac Medico wrote:
> Ignore the @world package set and its dependencies. This may be useful
> if there is a desire to perform an action even though it might break
> the dependencies of some installed packages (it might also remove
> installed packages in order to solve blockers). This also alters the
> behavior of --complete-graph options so that only deep dependencies
> of packages given as arguments are included in the dependency graph.
> This option may be useful as an alternative to --nodeps in cases where
> it is desirable to account for dependencies of packages given as
> arguments.
> 
> Bug: https://bugs.gentoo.org/608564
> ---
>  man/emerge.1  | 17 +
>  pym/_emerge/create_depgraph_params.py |  4 
>  pym/_emerge/depgraph.py   |  8 ++--
>  pym/_emerge/main.py   |  9 +
>  pym/portage/tests/resolver/test_complete_graph.py | 18 ++
>  5 files changed, 54 insertions(+), 2 deletions(-)
> 
> diff --git a/man/emerge.1 b/man/emerge.1
> index a17b65ed2..01ce62e51 100644
> --- a/man/emerge.1
> +++ b/man/emerge.1
> @@ -630,6 +630,23 @@ Therefore, \fB\-\-usepkgonly\fR (or 
> \fB\-\-getbinpkgonly\fR) must be
>  used in order to enable soname depedency resolution when installing
>  packages.
>  .TP
> +.BR "\-\-ignore\-world [ y | n ]"
> +Ignore the @world package set and its dependencies. This may be useful
> +if there is a desire to perform an action even though it might break
> +the dependencies of some installed packages (it might also remove
> +installed packages in order to solve blockers). This also alters the
> +behavior of \fB\-\-complete\-graph\fR options so that only deep
> +dependencies of packages given as arguments are included in the
> +dependency graph. This option may be useful as an alternative to
> +\fB\-\-nodeps\fR in cases where it is desirable to account for
> +dependencies of packages given as arguments.
> +
> +\fBWARNING:\fR
> +This option is intended to be used only with great caution, since it is
> +possible for it to make nonsensical changes which may lead to system
> +breakage. Therefore, it is advisable to use \fB\-\-ask\fR together with
> +this option.
> +.TP
>  .BR \-j\ [JOBS] ", "  \-\-jobs[=JOBS]
>  Specifies the number of packages to build simultaneously. If this option is
>  given without an argument, emerge will not limit the number of jobs that can
> diff --git a/pym/_emerge/create_depgraph_params.py 
> b/pym/_emerge/create_depgraph_params.py
> index fc7fa60d7..0405011fd 100644
> --- a/pym/_emerge/create_depgraph_params.py
> +++ b/pym/_emerge/create_depgraph_params.py
> @@ -26,6 +26,7 @@ def create_depgraph_params(myopts, myaction):
>   # ignore_soname_deps: ignore the soname dependencies of built
>   #   packages, so that they do not trigger dependency resolution
>   #   failures, or cause packages to be rebuilt or replaced.
> + # ignore_world: ignore the @world package set and its dependencies
>   # with_test_deps: pull in test deps for packages matched by arguments
>   # changed_deps: rebuild installed packages with outdated deps
>   # changed_deps_report: report installed packages with outdated deps
> @@ -56,6 +57,9 @@ def create_depgraph_params(myopts, myaction):
>   myparams["selective"] = True
>   return myparams
>  
> + if myopts.get('--ignore-world') is True:
> + myparams['ignore_world'] = True
> +
>   rebuild_if_new_slot = myopts.get('--rebuild-if-new-slot')
>   if rebuild_if_new_slot is not None:
>   myparams['rebuild_if_new_slot'] = rebuild_if_new_slot
> diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
> index 6c728684f..f7ea27c37 100644
> --- a/pym/_emerge/depgraph.py
> +++ b/pym/_emerge/depgraph.py
> @@ -163,7 +163,10 @@ class _frozen_depgraph_config(object):
>   self.trees[myroot]["bintree"] = DummyTree(
>   
> DbapiProvidesIndex(trees[myroot]["bintree"].dbapi))
>  
> - self._required_set_names = set(["world"])
> + if params.get("ignore_world", False):
> + self._required_set_names = set()
> + else:
> + self._required_set_names = set(["world"])
>  
>   atoms = ' '.join(myopts.get("--exclude", [])).split()
>   self.excluded_pkgs = _wildcard_set(atoms)
> @@ -7554,6 +7557,7 @@ class depgraph(object):
>   ignored_uninstall_tasks = set()
>   have_uninstall_task = False
>   complete = "complete" in self._dynamic_config.myparams
> + ignore_world = 
> self._dynamic_config.myparams.get("ignore_world", False)
>   asap_nodes = []
>  
>   def 

[gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)

2018-03-21 Thread Zac Medico
Ignore the @world package set and its dependencies. This may be useful
if there is a desire to perform an action even though it might break
the dependencies of some installed packages (it might also remove
installed packages in order to solve blockers). This also alters the
behavior of --complete-graph options so that only deep dependencies
of packages given as arguments are included in the dependency graph.
This option may be useful as an alternative to --nodeps in cases where
it is desirable to account for dependencies of packages given as
arguments.

Bug: https://bugs.gentoo.org/608564
---
 man/emerge.1  | 17 +
 pym/_emerge/create_depgraph_params.py |  4 
 pym/_emerge/depgraph.py   |  8 ++--
 pym/_emerge/main.py   |  9 +
 pym/portage/tests/resolver/test_complete_graph.py | 18 ++
 5 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/man/emerge.1 b/man/emerge.1
index a17b65ed2..01ce62e51 100644
--- a/man/emerge.1
+++ b/man/emerge.1
@@ -630,6 +630,23 @@ Therefore, \fB\-\-usepkgonly\fR (or 
\fB\-\-getbinpkgonly\fR) must be
 used in order to enable soname depedency resolution when installing
 packages.
 .TP
+.BR "\-\-ignore\-world [ y | n ]"
+Ignore the @world package set and its dependencies. This may be useful
+if there is a desire to perform an action even though it might break
+the dependencies of some installed packages (it might also remove
+installed packages in order to solve blockers). This also alters the
+behavior of \fB\-\-complete\-graph\fR options so that only deep
+dependencies of packages given as arguments are included in the
+dependency graph. This option may be useful as an alternative to
+\fB\-\-nodeps\fR in cases where it is desirable to account for
+dependencies of packages given as arguments.
+
+\fBWARNING:\fR
+This option is intended to be used only with great caution, since it is
+possible for it to make nonsensical changes which may lead to system
+breakage. Therefore, it is advisable to use \fB\-\-ask\fR together with
+this option.
+.TP
 .BR \-j\ [JOBS] ", "  \-\-jobs[=JOBS]
 Specifies the number of packages to build simultaneously. If this option is
 given without an argument, emerge will not limit the number of jobs that can
diff --git a/pym/_emerge/create_depgraph_params.py 
b/pym/_emerge/create_depgraph_params.py
index fc7fa60d7..0405011fd 100644
--- a/pym/_emerge/create_depgraph_params.py
+++ b/pym/_emerge/create_depgraph_params.py
@@ -26,6 +26,7 @@ def create_depgraph_params(myopts, myaction):
# ignore_soname_deps: ignore the soname dependencies of built
#   packages, so that they do not trigger dependency resolution
#   failures, or cause packages to be rebuilt or replaced.
+   # ignore_world: ignore the @world package set and its dependencies
# with_test_deps: pull in test deps for packages matched by arguments
# changed_deps: rebuild installed packages with outdated deps
# changed_deps_report: report installed packages with outdated deps
@@ -56,6 +57,9 @@ def create_depgraph_params(myopts, myaction):
myparams["selective"] = True
return myparams
 
+   if myopts.get('--ignore-world') is True:
+   myparams['ignore_world'] = True
+
rebuild_if_new_slot = myopts.get('--rebuild-if-new-slot')
if rebuild_if_new_slot is not None:
myparams['rebuild_if_new_slot'] = rebuild_if_new_slot
diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index 6c728684f..f7ea27c37 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -163,7 +163,10 @@ class _frozen_depgraph_config(object):
self.trees[myroot]["bintree"] = DummyTree(

DbapiProvidesIndex(trees[myroot]["bintree"].dbapi))
 
-   self._required_set_names = set(["world"])
+   if params.get("ignore_world", False):
+   self._required_set_names = set()
+   else:
+   self._required_set_names = set(["world"])
 
atoms = ' '.join(myopts.get("--exclude", [])).split()
self.excluded_pkgs = _wildcard_set(atoms)
@@ -7554,6 +7557,7 @@ class depgraph(object):
ignored_uninstall_tasks = set()
have_uninstall_task = False
complete = "complete" in self._dynamic_config.myparams
+   ignore_world = 
self._dynamic_config.myparams.get("ignore_world", False)
asap_nodes = []
 
def get_nodes(**kwargs):
@@ -7971,7 +7975,7 @@ class depgraph(object):
# detected as early as possible, which 
makes it possible
# to avoid calling 
self._complete_graph() when it is
# unnecessary 

Re: [gentoo-dev] Project:Lisp without members

2018-03-21 Thread Pacho Ramos
El mié, 21-03-2018 a las 10:51 +0200, Mart Raudsepp escribió:
> Ühel kenal päeval, L, 10.03.2018 kell 13:26, kirjutas Pacho Ramos:
> > From now Project:Lisp has no members... that doesn't seem an issue as
> > it
> > contains multiple subprojects that maintain relevant packages... but,
> > for the
> > case anyone wants to join the main project...
> > https://wiki.gentoo.org/wiki/Project:Lisp
> 
> This is a valid setup of projects to my knowledge. Please correct me if
> I'm wrong. Don't undertake parent projects if they have subprojects
> with active members please. In other words, please don't undertake a
> project if it has active subprojects, if that was your mails intention
> here.
> https://wiki.gentoo.org/wiki/Project:Lisp even lists subprojects and
> their members as part of lisp project. Though it seems to have gotten a
> direct member now too to prevent the implicit undertaking intention
> (which I think is unnecessary).
> 
> 
There were no "undertaking intention" for that parent project as the mail states
showing no warning about removing it and even suggesting that "it doesn't seem
an issue"... the intention was merely to inform people for the case someone
wanted to joing the Project



Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Rich Freeman
On Wed, Mar 21, 2018 at 12:55 PM, R0b0t1  wrote:
>
> I can't tell, and I suspect other people can't either.
>

This is the crux of the issue.  Decisions involving people issues are
made behind closed doors, which means that others are not free to
confirm for themselves whether those actions are correct.  This tends
to lead to ongoing debate over whether those decisions were
appropriate, with everybody arguing from their own knowledge, and the
only ones who know the information used to make the decision are
barred from talking about it.  This is basically a debate where
participation is limited to the ignorant, at least as far as the
particular details go (the general principles are debated by all).

That said, even if the decisions were made in the open I wouldn't
expect all to agree with them.

Ultimately though there are pros and cons to making these kinds of
decisions in the open, and there is not universal agreement regarding
how these situations ought to be handled.  We can either fight about
it until the end of time, or we can agree on some way to determine
what approach we are going to take and then support it (perhaps
begrudgingly).  Right now the mechanism that we have in place is the
Council.  The only other mechanism I could see that would make any
sense would be a referendum on the issue.  That gets unwieldy if we
try to apply it to every little decision, but maybe for the big
picture issues it would make sense.

However, I think a lot of people would be surprised at the outcome.
We all assume that we're all here for the same reasons, but as I
commented on my blog Gentoo is a bit unique among distros and many of
us are here for very different reasons, and have different priorities.
Also, there is sometimes a tendency to assume that all FOSS projects
work the same way.  When I was listening to a talk about how one of
the BSDs dealt with these kinds of issues I was shocked to discover
that much of their dev communications happens on completely closed
lists (not just closed to posting, but to reading as well).  Gentoo
has the gentoo-core list but it is very low traffic and it tends to be
used for things like swapping cell phone numbers before conferences.
When anything substantive comes up there are usually several people
who chime in to rightly point out that this talk belongs on a public
list.

Bottom line is that there are a lot of different ways projects can
run, and they all have their pros and cons.  A lot of the FOSS we
depend on actually gets built or discussed behind closed doors.  I
doubt many of us want Gentoo to go that far, but I suspect there is a
lot of interest in taking smaller steps in that general direction.

-- 
Rich



Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread R0b0t1
On Wed, Mar 21, 2018 at 9:44 AM, Alec Warner  wrote:
> The community has a 'toxic people problem'

Maybe certain people who feel they are being attacked are idiots and
don't like hearing it? I can't tell, and I suspect other people can't
either.

Respectfully,
 R0b0t1



Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Alec Warner
On Wed, Mar 21, 2018 at 12:31 PM, Eray Aslan  wrote:

> On Wed, Mar 21, 2018 at 10:44:48AM -0400, Alec Warner wrote:
> > [1] Which isn't to say that I would accept 'orders' to commit crimes, or
> > other obviously bad things.
>
> This is the crux of the problem.  There are certain lines you will not
> cross.  I am saying that my line is different and by voicing that,
> hopefully, making you re-consider yours.
>
> > I'm again asserting that this idea is not
> > fundamentally bad. The community has a 'toxic people problem' and our
> > previous attempts at resolution have not really produced great results.
> > Will this also produce great results? Not sure. But willing to try it.
>
> Openness, transparency, inclusiveness.  Those are some pretty
> fundemental values.  Reconsider.  But if you decide to go ahead, I am
> not going to judge you.  You (or the council members who voted yes) are
> not bad persons.  Just somewhat different values - which is surprising
> in a sad way.
>

I think of my aim is just playing a longer field here. I've been a part of
Gentoo for a long time. I've considered leaving numerous
times for a variety of reasons; yet I remain.

I don't disagree that the issue is important, but leaving an organization
really changes the velocity and direction of influence one
can have on it. Traditionally I have not seen external contributors have a
strong influence in Gentoo; so leaving to me implies a
loss of influence. If my goal is to have a good outcome; I'm not convinced
leaving accomplishes it. If I leave, will the council change their mind?
Why would they?

Perhaps you think myself (and other developers) should do more and I think
that is a reasonable thing to advocate for; but I'm also fairly happy with
a timeline
of:

1) We add moderation in ~April.
2) Council election happens in summer (I expect something of a strong
reckoning here, in terms of council makeup.)
3) Council` repeals the previous decision and we undo the moderation[1].

I tend to like this approach because I feel like its how the organization
was designed to work. I think alternatives involve essentially
'protesting'. E.g. I could propose the council discuss this topic at every
meeting. I could try to use my developer-ship to force extra council
meetings (emergency meetings perhaps.) I could collect signatures. I'm
still not convinced these things would be vehicles for change though.

[1] There is of course the risk that this doesn't come about, either
because the same council is re-elected or because the new council chooses
not to repeal. But I accept this risk willingly.


> --
> Eray
>
>


Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Eray Aslan
On Wed, Mar 21, 2018 at 10:44:48AM -0400, Alec Warner wrote:
> [1] Which isn't to say that I would accept 'orders' to commit crimes, or
> other obviously bad things.

This is the crux of the problem.  There are certain lines you will not
cross.  I am saying that my line is different and by voicing that,
hopefully, making you re-consider yours.

> I'm again asserting that this idea is not
> fundamentally bad. The community has a 'toxic people problem' and our
> previous attempts at resolution have not really produced great results.
> Will this also produce great results? Not sure. But willing to try it.

Openness, transparency, inclusiveness.  Those are some pretty
fundemental values.  Reconsider.  But if you decide to go ahead, I am
not going to judge you.  You (or the council members who voted yes) are
not bad persons.  Just somewhat different values - which is surprising
in a sad way.

-- 
Eray



Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Alec Warner
On Wed, Mar 21, 2018 at 1:36 AM, Eray Aslan  wrote:

> On Tue, Mar 20, 2018 at 10:28:48AM -0500, Matthew Thode wrote:
> > While I personally do no agree with mailing list moderation infra has
> > been tasked with moving forward on it.
>
> You can always resign from infra.
>

> That was a somewhat tongue-in-cheek comment but not wholly.  You cant
> cop out by saying it was an order from council.  I understand if you
> dont but do consider it.  Fight the good fight.
>

So when there is conflict its pretty often that you have 3 options.

1) Accept
2) Leave
3) Escalate

I'm not sure 3 is possible (the council is already the highest body). I
also think that as a organization this is how we
arranged it to be. Speaking for myself, this is not the worst issue I've
seen in Gentoo and so I thing doing 2 is probably
not very effective. Its also likely I can only do 2 once (because maybe I
would not be welcome'd back or want to contribute anymore.)

That leaves 1 and one interests me for many reasons.

a) as noted earlier, decisions are not set in stone. Its possible we could
turn on this whitelisting solution for a brief period and the decision is
overturned at the next council meeting, or perhaps at the next council
election once the existing council is replaced.
b) I am never afraid of making mistakes. I too think this is a mistake; but
I don't think its a critical mistake for the organization. Maybe I'm wrong
though.
c) I have a selfish interest to migrate off of mmlmj because I have an
intense dislike (of the software) and I think we need a "modernized" list
setup. So this effort is a driver to get some infra work done.
d) Infra as a organization wields a lot of power in Gentoo and I think its
organizationally dangerous to wield that power in this way. For example, if
the entire infra team retired rather than implement this solution; or even
worse, refused to retire but just didn't implement it. Ultimately
Infrastructure is here to meet the needs of the distribution and if we are
not doing that then we have failed as an organization.[1]
e) In the past, infra *has* wielded its power in a fashion that had
negative impacts on the distribution (e.g. arbitrarily removing commit
rights for developers with no warning, process, or oversight). I think
there is an additional focus in the the Infra team to avoid that sort of
activity and "inaction is still action" and I think it results in similar
repercussions.

[1] Which isn't to say that I would accept 'orders' to commit crimes, or
other obviously bad things. I'm again asserting that this idea is not
fundamentally bad. The community has a 'toxic people problem' and our
previous attempts at resolution have not really produced great results.
Will this also produce great results? Not sure. But willing to try it.

-A

>
> --
> Eray
>
>


Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

2018-03-21 Thread Herb Miller Jr .
On 03/21/2018 03:33 AM, Kent Fredric wrote:
> On Wed, 21 Mar 2018 01:44:11 +
> Herb Miller Jr.  wrote:
>
>> If I am, then yes, some kind of automation
>> would be the only sane way to keep up
> In my experience you can't *really* rely on automation 100% for this
> sort of thing. Not while achieving quality results.
>
> Its viable for an overlay where there's no expectations of quality, but
> for the main tree, I find you want to have a human san-check everything
> and manually vet each upstream version for "anomalous things".
>
> Automation is good at handling the "known predictable" cases, humans
> are better at detecting "huh, that's weird, why did they do that?"
>
> Because you absolutely want to know if upstream added some stupid
> change that is harmful to Gentoo users before you blindly replicate it.

And I agree with you 100%. I would never rely on automation exclusively.
I would use it to write boilerplate sections, check for updates, check
for breakage, etc. I'd never open a PR for something I hadn't polished
myself.




[gentoo-dev] Pypi generator (Was: [RFC] Begin a dev-libs/nodejs category?)

2018-03-21 Thread Benda Xu
X dej  writes:

> I did not find anything wannabe "g-pip" for python.

Check out app-portage/gs-pypi.



Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Rich Freeman
On Wed, Mar 21, 2018 at 1:36 AM, Eray Aslan  wrote:
> On Tue, Mar 20, 2018 at 10:28:48AM -0500, Matthew Thode wrote:
>> While I personally do no agree with mailing list moderation infra has
>> been tasked with moving forward on it.
>
> That was a somewhat tongue-in-cheek comment but not wholly.  You cant
> cop out by saying it was an order from council.  I understand if you
> dont but do consider it.  Fight the good fight.

Interesting.  When exactly should we all start ignoring the Council,
and when should we do what they say?  And what is the likely result of
that?

For all the complaining of "cabals" in Gentoo it seems odd to suggest
putting the final decisions of the one group that is about the least
democratic in the organization.

(That isn't really intended as a criticism: there are a lot of
practical reasons why infra operates as it does and I've yet to come
up with any better approach.  With the council/trustees the authority
comes from the collective, and nobody would pay attention to a
directive that didn't have a majority backing or the appearance of due
process.  With any other project the decisions are appealable to
council.  With infra one guy with the root password can cause a lot of
havoc, and the computer isn't going to stop and question what they're
doing.  That creates a lot of incentive to minimize the number of
people who are trusted.  In any case, I think it makes the most sense
to do the decision-making in more open/democratic processes, and then
minimize the execution footprint that requires "cabals.")

As I've commented elsewhere [1] I think an issue here is that we just
don't have enough of a critical mass to be able to afford to split
along ideological lines.  The set of developers interested in a
source-based distro is barely sufficient to create a viable
source-based distro.  If you split it into the subsets who prefer open
vs closed mailing lists on top of this then the individual groups lack
critical mass.  And so we're forced to co-exist, and agree on one or
the other, or some kind of compromise.

1 - 
https://rich0gentoo.wordpress.com/2016/02/27/gentoo-ought-to-be-about-choice/

-- 
Rich



Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

2018-03-21 Thread X dej
2018-03-21 2:44 UTC+01:00, Herb Miller Jr. :
>>> When I did my homework on creating nodejs ebuilds (not nodejs itself
>>> but packages written in node), it seems the topic has come up a few
>>> times in the past but the time commitment and general disorganization
>>> of upstream has scared off any serious attempts at packaging.

Dear Herb,

I would like to make sure that you knew about the disorganized and outdated
attempt named app-portage/g-npm:
URL: 
https://www.reddit.com/r/Gentoo/comments/38txil/how_do_you_guys_manage_languagespecific_package/
Title: "How do you guys manage language-specific package managers
(npm, gem, pip, etc)? : Gentoo"

I found out about that while trying to make an ebuild for
www-apps/etherpad-lite-1.2.91, see https://bugs.gentoo.org/328897 for
that.

You might also want to know about that attempt:
https://forums.gentoo.org/viewtopic-t-1064550-start-0.html
titled "Portage and NodeJS and similarity with Python, Perl, etc."

Perl monks using gentoo might want to know about app-portage/g-cpan, see first
URL above.

I just found out that app-portage/g-octave app-portage/g-sorcery existed.

I did not find anything wannabe "g-pip" for python.

-- 
xdej@#gentoo-prefix



Re: [gentoo-dev] Project:Lisp without members

2018-03-21 Thread Mart Raudsepp
Ühel kenal päeval, L, 10.03.2018 kell 13:26, kirjutas Pacho Ramos:
> From now Project:Lisp has no members... that doesn't seem an issue as
> it
> contains multiple subprojects that maintain relevant packages... but,
> for the
> case anyone wants to join the main project...
> https://wiki.gentoo.org/wiki/Project:Lisp

This is a valid setup of projects to my knowledge. Please correct me if
I'm wrong. Don't undertake parent projects if they have subprojects
with active members please. In other words, please don't undertake a
project if it has active subprojects, if that was your mails intention
here.
https://wiki.gentoo.org/wiki/Project:Lisp even lists subprojects and
their members as part of lisp project. Though it seems to have gotten a
direct member now too to prevent the implicit undertaking intention
(which I think is unnecessary).




Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

2018-03-21 Thread Kent Fredric
On Wed, 21 Mar 2018 01:44:11 +
Herb Miller Jr.  wrote:

> If I am, then yes, some kind of automation
> would be the only sane way to keep up

In my experience you can't *really* rely on automation 100% for this
sort of thing. Not while achieving quality results.

Its viable for an overlay where there's no expectations of quality, but
for the main tree, I find you want to have a human san-check everything
and manually vet each upstream version for "anomalous things".

Automation is good at handling the "known predictable" cases, humans
are better at detecting "huh, that's weird, why did they do that?"

Because you absolutely want to know if upstream added some stupid
change that is harmful to Gentoo users before you blindly replicate it.


pgp0LJHitrNJn.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-perl/WWW-Bugzilla

2018-03-21 Thread Kent Fredric
# Kent Fredric  (21 Mar 2018)
# Not usable with versions of Bugzilla shipped by Gentoo since 2013,
# Dead upstream. Use dev-perl/BZ-Client instead.
# Removal in 30 days. Bug 651056
dev-perl/WWW-Bugzilla


pgpOQtW1bOeQa.pgp
Description: OpenPGP digital signature