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".
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
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),
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
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
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 . 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
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 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. > >  profiles/features/hardened/amd64/no-multilib Regards, Alon
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 in place and is working if explicitly added. > Thanks, > Alon > >  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 . 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.
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 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. >  profiles/features/hardened/amd64/no-multilib -- Best regards, Michał Górny
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 in place and is working if explicitly added. > Thanks, > Alon > >  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.
Hi, Any reason we do not publish hardened/no-multilib? I see we have in place and is working if explicitly added. Thanks, Alon  profiles/features/hardened/amd64/no-multilib
# Michael Palimaka
(02 Dec 2017) # Depends on dead Qt 4. Dead upstream. # Masked for removal in 30 days. Bug #639252. dev-vcs/qsvn