[gentoo-dev] We Are All wltjr On This Blessed Day

[R0b0t1]

19:09   @floppym | wltjr really seems to make shit up when he
doen't know what he's talking about.
19:20@mgorny | lol
19:20@mgorny | we're talking about the real wltjr or the
r0b0t1 fake identity?
19:21   @floppym | mgorny: There's a fake?
19:22@mgorny | didn't you notice r0b0t1 on the mailing lists?
19:22   @floppym | Nope.
19:22   @floppym | I'm talking about the person filing bugs about
Portage failures on NFS, as well as bug
 | 637160
19:22@mgorny | he appeared out of the blue a few weeks ago
19:22  willikins | floppym: https://bugs.gentoo.org/637160
"dev-python/pbr-3.1.1 access violation with pypy3";
 | Gentoo Linux, Current packages; UNCO;
wlt-ml:prometheanfire
19:25@mgorny |
https://archives.gentoo.org/gentoo-dev/message/7f2b9a05baf062acc8bf7b539949f5b9
19:25@mgorny | this guy
19:25   @floppym | Oh, yes. He seems to conherent to be wltjr.
19:26@mgorny | 'i know nothing but i'm going to pretend i'm
the smartest guy around, and try to prove
 | everyone who disagrees with me is stupid'
19:27   @floppym | I see posts from him dating back to 2016; I
think it's a different person.
19:28 jstein | But this robot seems to need some kind of
repair or recalibration in my eyes
19:29@mgorny | floppym: maybe. but he behaves quite similar
19:31  * | floppym shrugs
19:32 jstein | the members on our mailinglist handle this
troll very well and do not get triggered by his
 | statements.
19:32   @floppym | If only the same could be said for wltjr...
19:34--> | fekepp
(~Thunderbi@2a02:8071:31ac:c00:221:ccff:fed4:6de7) has joined
#gentoo-python
19:34 jstein | where do I remember this nick from? Bugs?
19:36 jstein | the robot did not write any mail after 9th. I
expected he was set to "moderated".

Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

[R0b0t1]

Hello,

In every mailing list conversation, there are at least three people:
the two conversing, and the future reader. I point this out as I think
it important that everyone realize that not all posts are written for
those immediately participating in the conversation.

Some time ago I was offered some equipment due to my history of
open-source contributions to a variety of projects. I asked the donor
to forward it (or money) to the Gentoo foundation, but they declined,
citing a general distaste for the management of software projects in
general and specific issues they believed existed within Gentoo.


On Sat, Dec 2, 2017 at 5:18 PM, Michał Górny  wrote:
> Hello, everyone.
>
> This is something that's been talked about privately a lot lately but it
> seems that nobody went forward to put things into motion. SO here's
> a proposal that aims to improve the condition of our mailing lists
> and solve some of the problems they are facing today.
>

If you have in fact discussed this off list with people who agree, I
think it is important that you invite them to comment. Not only will
it show support for what you have detailed, it will allow them to
explain the problems they have in greater detail, so that perhaps a
solution that does not involve restricting list access could be found.

It may be that I am misunderstanding your language, but what you have
presented does not leave many things open for discussion. It seems
like what you have presented is to be either accepted or rejected as
is. Seeing as my opinion does not matter, it further seems like it
will simply be accepted as is.

>
> Problems
> 
>
> Currently the developer-oriented mailing lists gentoo-dev and gentoo-
> project are open to posting by everyone. While this has been generally
> beneficial, we seem to be having major problems with some
> of the posters for more than a year. Off hand, I can think of three:
>
> 1. Repeating attacks against Gentoo and/or Gentoo developers (including
> pure personal attacks). While it is understandable that some people may
> be frustrated and need to vent off, repeating attacks from the same
> person are seriously demotivating to everyone.
>

No one has any right to not be offended. If Gentoo developers are
receiving criticism for their behavior, then perhaps it would be best
that they critically analyze their actions and the effect that they
have on other people.

As far as I am aware most developers never get harassed and go quietly
on about their business. I have even asked some questions similar to
the questions I have asked on this list that people have felt were
adversarial. However, these developers didn't seem to mind my
questions and spent 5 minutes or so of their time on a response.

> 2. Frequent off-topics, often irrelevant to the thread at hand.
> I understand that some of those topics are really interesting but it is
> really time-consuming to filter through all the off-topic mails
> in search of data relevant to the topic at hand. What's worst, sometimes
> you don't even get a single on-topic reply.
>

Does the list have a digest subscription option? I find that extremely
helpful for one list I am subscribed to (Perl6 development) which is
very high volume. On the other hand, lots of offtopic chatter would
still be hard to sort through, but I think it needs to be considered
whether the chatter the list currently receives is truly off topic.
What if it is simply concerns or subjects that the OP did not want to
consider? Does that make it off topic? Is the problem more involved
than previously thought?

> 3. Support requests. Some of our 'expert users' have been abusing
> the mailing lists to request support (because it's easier to ask
> everyone than go through proper channels) and/or complain about bug
> resolutions. This is a minor issue but still it is one.
>

In the case of actual support requests, it might be worth taking some
kind of action against the user, but the general level of competence
of Gentoo users makes me wary that this may be a mischaracterization
of the intent of the email. If something like a "support request"
percolates to gentoo-dev, it may be of a similar vein as a complaint
about a bug resolution. Complaining about bug resolutions seems valid,
especially if questions on the tracker have been ignored.

Some developers in particular seem to not appreciate being held
accountable for their actions. In most notable cases, all anyone ever
does is ask for an explanation as to why something occurred - and in
most notable cases, that question is ignored, with no recourse left to
the user or contributor.

Personally, I tried to ask why eix's "optimizations" flag was removed,
when other packages *do the exact same thing.* Still no response. How
am I supposed to interpret this?

>
> All of those issues are slowly rendering the mailing lists impossible to
> use. People waste a lot of time trying to gather feedback, and get
> demotivated in the process. A 

[gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

[Michał Górny]

Hello, everyone.

This is something that's been talked about privately a lot lately but it
seems that nobody went forward to put things into motion. SO here's
a proposal that aims to improve the condition of our mailing lists
and solve some of the problems they are facing today.


Problems


Currently the developer-oriented mailing lists gentoo-dev and gentoo-
project are open to posting by everyone. While this has been generally
beneficial, we seem to be having major problems with some
of the posters for more than a year. Off hand, I can think of three:

1. Repeating attacks against Gentoo and/or Gentoo developers (including
pure personal attacks). While it is understandable that some people may
be frustrated and need to vent off, repeating attacks from the same
person are seriously demotivating to everyone.

2. Frequent off-topics, often irrelevant to the thread at hand.
I understand that some of those topics are really interesting but it is
really time-consuming to filter through all the off-topic mails
in search of data relevant to the topic at hand. What's worst, sometimes
you don't even get a single on-topic reply.

3. Support requests. Some of our 'expert users' have been abusing
the mailing lists to request support (because it's easier to ask
everyone than go through proper channels) and/or complain about bug
resolutions. This is a minor issue but still it is one.


All of those issues are slowly rendering the mailing lists impossible to
use. People waste a lot of time trying to gather feedback, and get
demotivated in the process. A steadily growing number of developers
either stop reading the mailing lists altogether, or reduce their
activity.

For example, eclass reviews usually don't get more than one reply,
and even that is not always on-topic. And after all, getting this kind
of feedback is one of the purposes of the -dev mailing list!


Proposal


Give the failure of other solutions tried for this, I'd like to
establish the following changes to the mailing lists:

1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be
initially restricted to active Gentoo developers.

1a. Subscription (reading) and archives will still be open.

1b. Active Gentoo contributors will be able to obtain posting access
upon being vouched for by an active Gentoo developer.

2. A new mailing list 'gentoo-expert' will be formed to provide
a discussion medium for expert Gentoo users and developers.

2a. gentoo-expert will have open posting access like gentoo-dev has now.


Rationale
=

I expect that some of you will find this a drastic measure. However, I
would like to point out that I believe we've already exhausted all other
options to no avail.

The problems of more abusive behavior from some of the mailing list
members have been reported to ComRel numerous times. After the failure
of initial enforcement, I'm not aware of ComRel doing anything to solve
the problem. The main arguments I've heard from ComRel members were:

A. Bans can be trivially evaded, and history proves that those evasions
create more noise than leaving the issue as is.

B. People should be allowed to express their opinion [even if it's pure
hate speech that carries no value to anyone].

C. The replies of Gentoo developers were worse [no surprise that people
lose their patience after being attacked for a few months].


The alternative suggested by ComRel pretty much boiled down to 'ignore
the trolls'. While we can see this is actually starting to happen right
now (even the most determined developers stopped replying), this doesn't
really solve the problem because:

I. Some people are really determined and continue sending mails even if
nobody replies to them. In fact, they are perfectly capable of replying
to themselves.

II. This practically assumes that every new mailing list subscriber will
be able to recognize the problem. Otherwise, new people will repeatedly
be lured into discussing with them.

III. In the end, it puts Gentoo in a bad position. Firstly, because it
silently consents to misbehavior on the mailing lists. Secondly, because
the lack of any statement in reply to accusations could be seen
as a sign of shameful silent admittance.


Yet another alternative that was proposed was to establish moderation of
the mailing lists. However, Infrastructure has replied already that we
can't deploy effective moderation with the current mailing list software
and I'm not aware of anyone willing to undergo all the necessary work to
change that.

Even if we were able to overcome that and be able to find a good
moderation team that can effectively and fairly moderate e-mails without
causing huge delays, moderation has a number of own problems:

α) the delays will make discussions more cumbersome, and render posting
confusing to users,

β) they will implicitly cause some overlap of replies (e.g. when N
different people answer the same question because they don't see earlier
replies until they're past moderation),

Re: [gentoo-dev] Packages up for grabs: robbat2 edition

[Kent Fredric]

On Thu, 30 Nov 2017 18:19:23 +
"Robin H. Johnson"  wrote:

> dev-perl/MogileFS-*

On behalf of the Perl team I can keep this on life support till it
ceases to be maintainable.

( And Perl is already on its maintainer list )


pgpsJ59UMf60E.pgp
Description: OpenPGP digital signature

[gentoo-dev] 9 9 9 What Gentoo should be....

[William L. Thomson Jr.]

Its from me, so it sucks, most can ignore, its spam, nothing useful, etc
Feel free to TLDR; For those that decide to :)

Netbeans 9, built under Java 9, running on Java 9 :) Like no where else!

http://www.enlightenment.org/ss/e-5a20b8eb0b3e91.03603173.jpg
http://www.enlightenment.org/ss/e-5a20b833eb1999.79359468.jpg
http://www.enlightenment.org/ss/e-5a20b8017cd974.90970763.jpg
http://www.enlightenment.org/ss/e-5a20bf75cc4179.53467093.jpg

http://www.enlightenment.org/ss/e-5a231d693eafb2.66824545.jpg

150+ packages, though platform only requires ~100 or so.

About need new category for netbeans-* packages
https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/dev-java/

Ebuilds are beautiful and elegantly minimal.
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-java/netbeans-csl-api/netbeans-csl-api-.ebuild

Even the eclass is minimal, where all the magic takes place
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/java-netbeans.eclass

Most of this meta package will be pushed into eclass and be minimal
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-util/netbeans/netbeans-.ebuild

Allowing packages/jars to install themselves on merge as part of
either a meta ebuild, in repo/tree, user created, or user installed for
custom platform creation.
https://platform.netbeans.org/screenshots.html

Tons of work, much more work to do before I can start coding again.
Need to fix some things for Java 9 and ideally provide patches/PRs to
upstream to help them move things along.

This is alpha stuff as Netbeans is moving to Apache and in transition.
But like it should be on Gentoo. It will be fully packaged and running
before actual release. Likely before release candidates and maybe beta.

https://github.com/apache/incubator-netbeans
https://github.com/apache/incubator-netbeans/archive/9.0-alpha-rc2.tar.gz
https://incubator.apache.org/projects/netbeans.html

None the less, this is what Gentoo should be. The latest and greatest
being added before release. Thus Zero day should be done.  Working with
upstreams to further development and move all things forward faster.

Rather than keep up or be current, Gentoo's falling behind and may fall
behind faster.

Moving Java Forward Faster
https://mreinhold.org/blog/forward-faster


Why the madness? Well the current 8.2 is insanity
I was hacking some stuff for Java 9 but was a waste of time...
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-java/netbeans-platform/netbeans-platform-8.2-r11.ebuild#L114

Plus the portage ant stuff and xml rewriters that fail to work for
something this big and complex. Thus build.xml patches in SRC_URI. Yuk
yuk yuk. In tree nastiness. Though fordfrog did a good job working
within the ant build system and Gentoo's constraints. Tons of bundled
binary deps. 

https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-apisupport/netbeans-apisupport-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-cnd/netbeans-cnd-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-dlight/netbeans-dlight-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-enterprise/netbeans-enterprise-8.2-r1.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-ergonomics/netbeans-ergonomics-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-extide/netbeans-extide-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-groovy/netbeans-groovy-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-harness/netbeans-harness-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-ide/netbeans-ide-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-java/netbeans-java-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-javacard/netbeans-javacard-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-javadoc/netbeans-javadoc-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-javafx/netbeans-javafx-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-mobility/netbeans-mobility-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-nb/netbeans-nb-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-php/netbeans-php-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-platform/netbeans-platform-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-profiler/netbeans-profiler-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-webcommon/netbeans-webcommon-8.2.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/netbeans-websvccommon/netbeans-websvccommon-8.2.ebuild


Compare those ebuilds to mine + eclass + netbeans meta ebuild. Mine has
no binary deps all 100% from source on system :) Its all much less to
maintain though more packages. But I 

Re: [gentoo-dev] profiles 17.0 hardened/no-multilib missing?

[William L. Thomson Jr.]

On Sat, 2 Dec 2017 16:13:47 -0500
Michael Orlitzky  wrote:
> 
> I'm not sure if anything is using that particular profile. I tried to
> create a new subprofile myself,
> 
> https://archives.gentoo.org/gentoo-hardened/message/ab7ef753aa88f21c8a05d667cf511a24
> 
> and wound up (indirectly) using arch/amd64/no-multilib as the parent
> instead of your [1]. I think USE="pic" by default is the only
> difference.
> 
> In any case, until it becomes official, I'm probably just going to
> fake the profile with a symlink to the no-multilib profile's
> use.mask. That at least prevents me from building a multilib gcc,
> glibc, and sandbox.

Having created some profiles myself for my own purposes. Seems Gentoo
could really use and benefit from Funtoo's Flavors and Mix-ins. Seems
a much better approach than the current profiles situation in Gentoo.
https://www.funtoo.org/Funtoo_Profiles


"This new system is really a completion of the original cascading
profile design that was co-designed by Daniel Robbins and Seemant
Kulleen and implemented by Seemant Kulleen as part of Portage."
https://www.funtoo.org/Funtoo_Profiles#History_and_Origins

-- 
William L. Thomson Jr.


pgp2HpSy9rLr7.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] profiles 17.0 hardened/no-multilib missing?

[Alon Bar-Lev]

On 2 December 2017 at 23:08, Michał Górny  wrote:
>
> W dniu sob, 02.12.2017 o godzinie 22∶43 +0200, użytkownik Alon Bar-Lev
> napisał:
> > Hi,
> > Any reason we do not publish hardened/no-multilib?
> > I see we have[1] in place and is working if explicitly added.
> >
>
> One reason might be that:

Thanks.

>
> 1) there's barely any use for it,

Well, I think that whoever use hardened barely use multilib.

> 2) we have too many profiles, and

This has not stopped us so far.

> 3) every added profile slows down repoman & pkgcheck seriously.

Only when using '-d', no?
Anyway, probably the default of hardened should be multilib so we end
up with the same number.

> > [1] profiles/features/hardened/amd64/no-multilib

Regards,
Alon

Re: [gentoo-dev] profiles 17.0 hardened/no-multilib missing?

[Michael Orlitzky]

On 12/02/2017 03:43 PM, Alon Bar-Lev wrote:
> Hi,
> Any reason we do not publish hardened/no-multilib?
> I see we have[1] in place and is working if explicitly added.
> Thanks,
> Alon
> 
> [1] profiles/features/hardened/amd64/no-multilib
> 

I'm not sure if anything is using that particular profile. I tried to
create a new subprofile myself,

https://archives.gentoo.org/gentoo-hardened/message/ab7ef753aa88f21c8a05d667cf511a24

and wound up (indirectly) using arch/amd64/no-multilib as the parent
instead of your [1]. I think USE="pic" by default is the only difference.

In any case, until it becomes official, I'm probably just going to fake
the profile with a symlink to the no-multilib profile's use.mask. That
at least prevents me from building a multilib gcc, glibc, and sandbox.

Re: [gentoo-dev] profiles 17.0 hardened/no-multilib missing?

[Michał Górny]

W dniu sob, 02.12.2017 o godzinie 22∶43 +0200, użytkownik Alon Bar-Lev
napisał:
> Hi,
> Any reason we do not publish hardened/no-multilib?
> I see we have[1] in place and is working if explicitly added.
> 

One reason might be that:

1) there's barely any use for it,

2) we have too many profiles, and

3) every added profile slows down repoman & pkgcheck seriously.

> [1] profiles/features/hardened/amd64/no-multilib

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] profiles 17.0 hardened/no-multilib missing?

[Nils Freydank]

Am Samstag, 2. Dezember 2017, 21:43:53 CET schrieb Alon Bar-Lev:
> Hi,
> Any reason we do not publish hardened/no-multilib?
> I see we have[1] in place and is working if explicitly added.
> Thanks,
> Alon
> 
> [1] profiles/features/hardened/amd64/no-multilib

Hi,

one of the devs said in #gentoo-hardend (IRC, Freenode) a day ago
it’s just not added yet and we should stay on the old one so long.

I personally guess there’s just too much other stuff in was pushed
deeper down on the todo lists.
-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] profiles 17.0 hardened/no-multilib missing?

[Alon Bar-Lev]

Hi,
Any reason we do not publish hardened/no-multilib?
I see we have[1] in place and is working if explicitly added.
Thanks,
Alon

[1] profiles/features/hardened/amd64/no-multilib

[gentoo-dev] Last rites: dev-vcs/qsvn

[Michael Palimaka]

# Michael Palimaka  (02 Dec 2017)
# Depends on dead Qt 4. Dead upstream.
# Masked for removal in 30 days. Bug #639252.
dev-vcs/qsvn