from:"William L. Thomson Jr."

On Wed, 6 Dec 2017 00:25:46 +0100
Kristian Fiskerstrand <k...@gentoo.org> wrote:
>
> One of the primary issues recently is that you keep bringing up old
> matters in a way that is a criticism of Gentoo overall, in various
> channels. We've heard it already, and to keep bringing it up doesn't
> add additional value to the discussion. So again, please reduce the
> volume of such posts.

Most all still exist, plus new ones. Yet noting new is done to address.
Nothing changes for the good. Rather instead keep doubling done on the
old direction which keeps having a destructive impact. Maybe new
people, still learning the same lessons over and over. Old ones still
trying to force things to work the way they have never and will never.

And you get upset when someone is crying a fowl? If you saw something
being neglected and suffering. You would just stand by silently?

-- 
William L. Thomson Jr.

pgp0TNiSymjQB.pgp
Description: OpenPGP digital signature

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

On Tue, 5 Dec 2017 18:22:34 -0500
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
>
> For the record and reading assumer's. All my actions were in public,
> basically on mailing lists starting with -nfp long ago. All action
> taken against me was in public visible on my developer bug. I have
> never communicated with ComRel former DevRel in private. Or had any
> action taken against me for anything I did in private. It was always
> public.

Sorry correction I have exchange emails, I think IRC short of
confirming via logs with ComRel/DevRel as part of action being taken
against. Any conduct being "punished" was in public. I have no problems
with any punishment interaction I had being made public. It would not be
any different than what is on mailing list or my bug.

Nothing I did privately caused the ball to start rolling. That was
all in public. I think the initial report against me was private

Again sorry I did not want to be lying.

-- 
William L. Thomson Jr.

pgp4gZp8xudFN.pgp
Description: OpenPGP digital signature

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

On Tue, 5 Dec 2017 18:02:01 -0500
Rich Freeman <ri...@gentoo.org> wrote:
>
> The problem is that with current policies if somebody in Comrel/etc
> had evidence to the contrary they would not be able to refute such a
> denial.  My example wasn't of wltjr specifically (at least not to my
> knowledge), but it just goes to the point of why having these sorts of
> things hashed out on the mailing lists on the first place. 

For the record and reading assumer's. All my actions were in public,
basically on mailing lists starting with -nfp long ago. All action taken
against me was in public visible on my developer bug. I have never
communicated with ComRel former DevRel in private. Or had any action
taken against me for anything I did in private. It was always public.

Any private information regarding me from 08 till today was generated
within Gentoo and does not involve me. If any exists. With the
exception of -core back in the day. Which again is a list, visible to
all devs then.

Sorry and no more from me. I just feel given how I am portrayed,
spoken of, action taken against, etc. I must clarify some things for the
public record. Which even despite all my actions being in public.
People still assume because research and thinking for yourself takes
time. Time I do not expect anyone to expend.

-- 
William L. Thomson Jr.

pgpZwG3wiX646.pgp
Description: OpenPGP digital signature

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

On Tue, 5 Dec 2017 17:25:21 -0500
Rich Freeman <ri...@gentoo.org> wrote:

> On Tue, Dec 5, 2017 at 5:19 PM, Kristian Fiskerstrand
> <k...@gentoo.org> wrote:
> > On 12/05/2017 11:12 PM, Rich Freeman wrote:  
> >
> >> And what would you do when somebody repeatedly sexually harasses
> >> other members of the community in private after being told to
> >> stop, and then acts as if they're the victim on the public mailing
> >> lists?  
> >
> > This doesn't seem relevant to the matter of splitting the lists, and
> > would certainly be a matter for comrel.
> >  
> What do you do when they keep posting manifestos or whatever on the
> lists every few months, or generally stirring up the community about
> how unjustly they're being treated?  When the appeal is to popular
> opinion, instead of the defined process for handling these appeals?

For readers who may assume. Along the lines of me being kicked. I have
never ever in my life ever done anything along those lines, nor was
kicked. What ever Rich is referring to is another person, not me

I may stir pot, annoy, write backwards, etc. I do not use profanity. I
do not harass people. My actions are all in public. I am not a fan of
private PM. I hated it as a Trustee!

In fact private harassment is why I stepped down as Trustee
Me receiving harassment from members of DevRel
None sexual, still was harassment none the less

-- 
William L. Thomson Jr.


pgp5436cBD0EY.pgp
Description: OpenPGP digital signature

Accidental spoofing -> Re: [gentoo-dev] We Are All wltjr On This Blessed Day

On Mon, 4 Dec 2017 18:01:39 -0500
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:

> On Mon, 4 Dec 2017 14:43:15 -0800
> Matt Turner <matts...@gentoo.org> wrote:
> >
> > Sorry. I think I was confusing a number of irritating things you've
> > done: email spoofing,  
> 
> That was a complete accident due to a new version of Kmail that had
> the from field editable by default. It was NOT intentional. Not the
> 1st time. The 2nd time was for confirmation. I was in disbelieve such
> abuse was even possible with @gentoo.org addresses. That was a
> shocking discovery given I have administrated mail severs for quite
> some time. In part why I use ASSP.

I filed a bug with KDE on that but of course went WONTFIX. I think its
horrible as it allows people to spoof, spam and do bad things...

Make From field in the composer read only
https://bugs.kde.org/show_bug.cgi?id=373313

Me personally I would never make software or change it to allow people
to make such a mistake. Others felt differently. I stopped using
Kmail2. I use Claws-mail now, but it also has editable from field :(

Email clients should only allow email address that are in configured
accounts. But that is my opinion. Others seem to feel differently. I
cannot see any good reasons for such really.

-- 
William L. Thomson Jr.

pgpUDnCxn4EyP.pgp
Description: OpenPGP digital signature

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

On Mon, 4 Dec 2017 14:43:15 -0800
Matt Turner <matts...@gentoo.org> wrote:
>
> Sorry. I think I was confusing a number of irritating things you've
> done: email spoofing,

That was a complete accident due to a new version of Kmail that had the
from field editable by default. It was NOT intentional. Not the 1st
time. The 2nd time was for confirmation. I was in disbelieve such
abuse was even possible with @gentoo.org addresses. That was a shocking
discovery given I have administrated mail severs for quite some time.
In part why I use ASSP.

> doing whatever you did to get banned from  GitHub

That should never have happened. Over this comment. You tell me does
this make any sense to ban someone from Gentoo's Github? Which did not
go through Comrel or any normal channels. That was Gentoo Github
administrator abuse. I said nothing here that was untrue.
https://github.com/gentoo/gentoo/pull/1721#issuecomment-300178677

As a result I mentioned it again on this PR and then stopped
responding. Given its off topic, I would be punished not the other.
I felt I should have responded to not be rude. Given their lengthy
response and any reply would be in detail. Just not worth it for me.
https://github.com/gentoo/gentoo/pull/6033

> and then that time ten years ago that you evaded a mailing
> list ban. My apologies.

Thank you, very few if any have ever said that. It makes a huge
difference! Not that I expect it from anyone. But I do try to say sorry
when I am wrong. Think that is a sign of an adult, or man.

In a nutshell others have cast their negative impression of me onto
others. Who because person A feels this way about me, person B does as
well and the rest of the dominos. No matter if its correct or not. That
has gone on for many years. Been publicly defamed, etc.
Even when I produce facts to counter it seems to not matter.

We are in the group thinking generation it seems. I am not perfect, but
I have never had bad intentions. I should never have been treated as I
have been for a very long time. I would never seek to treat others that
way. Even with the mistreatment I still do not respond in kind to
others. No profanities, etc. Its not in my nature publicly surely not
in written form.

I have a sailors mouth, but I have a hard time typing such words
Some may perceive disrespect or rudeness from me, but that maybe more
my blunt nature than intentional disrespect. I spent to much time in
the hood growing up. I know better, I am still alive... :)

-- 
William L. Thomson Jr.

pgpU89xjZTA1P.pgp
Description: OpenPGP digital signature

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

On Mon, 4 Dec 2017 13:26:26 -0800
Matt Turner <matts...@gentoo.org> wrote:

> On Mon, Dec 4, 2017 at 10:52 AM, William L. Thomson Jr.
> <wlt...@o-sinc.com> wrote:
> > That being said, that people find it acceptable to talk behind
> > another's back. Lobbing lots of insults. Then having the ego to
> > assume someone would create a fake identity. Any minimal research
> > can show otherwise.  
> 
> You did already evade a mailing list ban.

If your talking about on -nfp in 2008. It was a ban that should never
have happened in the first place. It surely made nothing better.

My single post after ban was point to make a point. That bans can be
easily circumvented. Also you DO NOT ban a just stepped down Trustee
from the -nfp list. That shows massive disrespect. More so given what
all I did. Other Trustees then still show me some respect over my
actions then. I also did not hide, people knew it was me. No fake
account etc. I do not hide ever.

No one questions why I stepped down. Then or now. Nor the actions of
those who motivated me to do that. Why? Because they were members of
DevRel then. Also living near Alec, and having weekly gathers. I know I
hung out with them a few times. It was more personal than anything
against me and that was wrong to use Gentoo for personal reasons.

The entire thing should never have happened. Alec can clear it up if he
will tell his side. But he remains silent, for obvious reasons for
years. I have called him out on this a few times. All it takes is a
simple response from him to clear the air. After all he went to DevRel.
Me being a problem is one Alec started by reporting me to DevRel. He is
at least in part fault for everything since then involving me.

One involved  then Jorge Manuel B. S. Vicetto  has been very bad for
Gentoo. I used to talk to Petteri Rati all the time. Seeing them in
the following presentation. It is of no surprise to me where Gentoo is
at now. I could see this coming, and I did nothing. I let others
convince me I was the problem so I went away. Yet things did not
improve in my absence. Maybe I wasn't the problem

Gentoo's Reform and Future (Petteri Räty, Jorge Manuel B. S.
Published on Feb 5, 2011
https://www.youtube.com/watch?v=UQ3vkUBQkyg

You can see me talking to Petteri here, after Jorges comments.
https://bugs.gentoo.org/135927#c5

-- 
William L. Thomson Jr.

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

Sorry last one, directed to Alec, but all should read.

On Mon, 4 Dec 2017 16:08:51 -0500
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
>
> You could at least realize being here since 2008. If your not the one
> making it better. Maybe do not give others a hard time or creating
> more noise. I do not feel you are part of the solution I am sorry.
> You had close to a decade to make a difference. This is where things
> are and I am not to blame for Gentoo's entire community and/or
> atmosphere

Alec I am not blaming you for all of Gentoo's issues, nor is any one
person responsible. What I do fault you for is the situation involving
me since 2008. Which at many times you could clear the air telling your
side which you admitted then only on -core. You let things spiral, and
you started it all. Thanks, but I would appreciate an apology. It was
wrong and has had cascading effects for over a decade now. Hardly your
intentions then or now.

You made a mistake, and eagerly went to DevRel reporting me. Which
started a ball rolling no one could stop. That simple admission can
change the tide some. If anything will clear up the misconception that
I was kicked when I left. Less than a week or so after stepping down as
a trustee.

Requested retirement out of protest or disgust is not the same as
being kicked.
https://bugs.gentoo.org/135927#c7

Anytime an elected Trustee doing good work steps down mid term. Others
should wonder why. If they leave entirely after. Someone did something
to drive them away. Its simple logic. Much less show others respect
which I was never. Which continues to this day. People will disrespect
me before showing respect. Others take it to an extreme, and its all
tolerated because its me, wltr the drama troll destroying Gentoo who
won't go away. Despite the fact I did for years

-- 
William L. Thomson Jr.

pgpMO4A80dt7s.pgp
Description: OpenPGP digital signature

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

On Mon, 4 Dec 2017 19:54:12 +
Peter Stuge <pe...@stuge.se> wrote:

> I'm quite unimpressed by how mgorny and jstein behave there.

Doesn't matter its ok because it was about me... I never did anything
of that nature or other stuff. Yet action was sought to be taken
against me years go and it propagates.

Mine was a trivial violation if that. Though its been used against me
many times since... Github, etc.
 https://bugs.gentoo.org/135927#c5

> I wouldn't accept that, were I leading the project.

Cyndi Lauper - True Color
https://www.youtube.com/watch?v=LPn0KFlbqX8

Wonder how they feel about others?

-- 
William L. Thomson Jr.

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

On Mon, 4 Dec 2017 21:29:26 +0100
Vincent-Xavier JUMEL <endymion+gen...@thetys-retz.net> wrote:
> 
> Please do rembember that you can't solve all earth problems, not even 
> all Gentoo problems :)

Technology is no means to resolve social issues. Our use of technology
is bringing about entirely new unique social issues. Technology creates
more social issues than it solves.

People all over the world will never get along. That does not mean they
should not have a place where they all come together for the benefit of
all. That is where magic happens!

-- 
William L. Thomson Jr.

pgpi0pu51nRtc.pgp
Description: OpenPGP digital signature

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

On Mon, 4 Dec 2017 14:54:38 -0500
Alec Warner <anta...@gentoo.org> wrote:
> 
> I think you make my point sir; not debase it. You did (and continue
> to do) many things, that are in fact
> valuable

What else may I have done since 08 had things been otherwise?
Gentoo's loss.

> However, you also contributed very negatively to the  community.

That is because the community needs to change. The atmosphere is
negative without me. I was gone from 08-15. So I am to blame for that
period.

> This isn't a simple maths  problem where as long as one does enough
> good they can offset the bad. I'm fairly confident the  community
> doesn't want such an environment (and have repeatedly rejected it in
> the past.)

My simple math shows you have been here the entire time. Clearly you
are not capable of making things better. Yet had a direct hand in
making it worse. Good job!

You could at least realize being here since 2008. If your not the one
making it better. Maybe do not give others a hard time or creating more
noise. I do not feel you are part of the solution I am sorry. You had
close to a decade to make a difference. This is where things are and I
am not to blame for Gentoo's entire community and/or atmosphere.

-- 
William L. Thomson Jr.

pgp8xFv9KLktq.pgp
Description: OpenPGP digital signature

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

On Mon, 4 Dec 2017 13:57:16 -0500
kuzetsa <kuze...@gmail.com> wrote:

> On 12/04/2017 01:51 PM, William L. Thomson Jr. wrote:
> > On Mon, 4 Dec 2017 13:15:32 +
> > "M. J. Everitt" <m.j.ever...@iee.org> wrote:
> >  
> >> On 04/12/17 00:37, Matt Turner wrote:  
> >>> A user requested I forward this information to the mailing list:
> >>>
> >>> http://www.hbs.edu/faculty/Publication%20Files/16-057_d45c0b4f-fa19-49de-8f1b-4b12fe054fea.pdf
> >>> https://goo.gl/42A8v7 (short URL of the same)
> >>>
> >>> ... and was itself cited a dozen or times:
> >>>
> >>> https://scholar.google.com/scholar?cites=5443947091657980238
> >>> https://goo.gl/obvdzh (short URL of the same)  
> > Anyone paying any attention to current events?  Quite many business
> > and governments have gone out of their way to protect and hide the
> > actions of abusers. In most causes because they were money makers.
> > I think that may contradict the article entirely.
> >  
> 1) harvard business school research publication, not an "article"

If you read it is called a working paper. Working Paper 16-057 
Which is an article, or more work in progress subject to review,
feedback, changes, etc.

https://en.wikipedia.org/wiki/Working_paper
https://www.princeton.edu/~pswpc/about/about.html
http://www.dictionary.com/browse/article

They have many 1502
http://www.hbs.edu/

Its confusing because on one page says Dylan Harvard Business School.
But he's clearly at Northwestern University. I assume a student at
Harvard Business school. Not sure hes relation.

Dylan Minor 
Harvard Business School 

Dylan Minor
Kellogg School of Management, Northwestern University
http://www.kellogg.northwestern.edu/faculty/directory/minor_dylan.aspx

-- 
William L. Thomson Jr.


pgpFBuBhwbuTR.pgp
Description: OpenPGP digital signature

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

It is interesting to see people discussing behavior on list while flat
out ignoring the following.

This person is NOT me! They showed in #gentoo-java the other day.
Prior to that I have never had any contact. They shared the below log
with me then. Which I found flattering and amusing. Haters will hate...

That being said, that people find it acceptable to talk behind another's
back. Lobbing lots of insults. Then having the ego to assume someone
would create a fake identity. Any minimal research can show otherwise.

Further more associating with them me given how they speak of me. That
immediately insults the other person for no reason. They likely had no
idea who I was till others accused them of being me... Which caused
them to research who I was and come to their own conclusions.

The entire situation is laughable and shows a huge double standard. Not
to mention a total lack of respect for others and immature behavior.
Gentoo's status quo

On Sat, 2 Dec 2017 21:49:44 -0600
R0b0t1 <r03...@gmail.com> wrote:

> 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".
> 

-- 
William L. Thomson Jr.

pgppVz4FpIqZj.pgp
Description: OpenPGP digital signature

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

On Mon, 4 Dec 2017 13:15:32 +
"M. J. Everitt" <m.j.ever...@iee.org> wrote:

> On 04/12/17 00:37, Matt Turner wrote:
> > A user requested I forward this information to the mailing list:
> >
> > http://www.hbs.edu/faculty/Publication%20Files/16-057_d45c0b4f-fa19-49de-8f1b-4b12fe054fea.pdf
> > https://goo.gl/42A8v7 (short URL of the same)
> >
> > ... and was itself cited a dozen or times:
> >
> > https://scholar.google.com/scholar?cites=5443947091657980238
> > https://goo.gl/obvdzh (short URL of the same)

Anyone paying any attention to current events?  Quite many business and
governments have gone out of their way to protect and hide the actions
of abusers. In most causes because they were money makers. I think that
may contradict the article entirely.

Steve Jobbs was a toxic coworker. Most titans in tech would fall more
into toxic category. Ever hear of Balmer raging or Gates? Ellison?
Google any of their names or others with a hole and see what you get

> I refer you also to a former Gentoo developer's talk on "A$$holes on
> your project" ... [1]
> 
> [1] - https://www.youtube.com/watch?v=-ZSli7QW4rg

Based on this graph have things gotten better since 08?
https://youtu.be/-ZSli7QW4rg?t=3m

Most every action since has hurt Gentoo big time. I left from 08 - 15.
I am not part of any of that. Why did it not recover with driving so
many out? That does way more harm than keeping people in

A lesson many have yet to learn...

As Donnie said conflict is good...
https://youtu.be/-ZSli7QW4rg?t=5m5s

As Steve Jobbs said in this metaphor
https://www.youtube.com/watch?v=K-Yv-UdsmSo

-- 
William L. Thomson Jr.

pgp2GSURTuk35.pgp
Description: OpenPGP digital signature

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

2017-12-02 Thread William L. Thomson Jr.

 have ebuild-bumper to help :)
https://github.com/Obsidian-StudiosInc/ebuild-bumper
https://github.com/Obsidian-StudiosInc/ebuild-bumper/blob/master/bump_pkgs/netbeans

I use it all the time to bump series of related packages. Major time
saver! Only way someone like me can maintain some 700+ ebuilds.
https://github.com/Obsidian-StudiosInc/os-xtoo

Most all maintained better than in tree and newer versions!
What Gentoo should be

-- 
William L. Thomson Jr.


pgp3A1rriRwmN.pgp
Description: OpenPGP digital signature

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

2017-12-02 Thread William L. Thomson Jr.

On Sat, 2 Dec 2017 16:13:47 -0500
Michael Orlitzky <m...@gentoo.org> 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] Re: cmake + ninja vs autotools

2017-11-24 Thread William L. Thomson Jr.

On Sat, 25 Nov 2017 00:20:38 +
Peter Stuge <pe...@stuge.se> wrote:

> William L. Thomson Jr. wrote:
> > I cannot understand why systems get faster, yet configure seems to
> > take the same amount of time and is super slow.  
> 
> The generated configure scripts can be fork intensive, which is still
> fairly expensive.
> 
> But I think the problem is more with poorly written configure source,
> which is the argument about mastering..

Not sure what can be done for minimal ones.

Meson 1.20s
https://travis-ci.org/Obsidian-StudiosInc/entrance/builds/291848344#L1033

Before I switched to meson
Configure/autotools 5.52s
https://travis-ci.org/Obsidian-StudiosInc/entrance/builds/270985567#L963

Original configure I dropped for meson
https://git.enlightenment.org/misc/entrance.git/tree/configure.ac


Or uber minimal, can't get much smaller still 5.20s
https://travis-ci.org/Obsidian-StudiosInc/asspr#L165
https://github.com/Obsidian-StudiosInc/asspr/blob/master/configure.ac

#secondsmatter :)

> > On small projects configure can take longer than compile...
> > Configure is my main gripe against make/autotools. Plus all the
> > other stuff, auto-reconf, autogen, etc.  
> 
> configure having zero dependencies is the killer feature compared
> to all other options. The tight integration between configure and
> cross-toolchains is also a very strong point.

The dependency aspect I agree with 100%. I think even cmake has more.
Meson requires python, so that alone has a big dependency chain. Which
some what surprises me so many with libraries are going that route. I
guess they figure it is not core, python likely to be present.

Or who cares about end users, its all about saving devs time, no clue.
#mesonbandwagon

> > The larger the project, the slower configure can be.  
> 
> Doesn't have to be, but it's easy to write poor configure source and
> difficult to write good source.

I would assume then most are poorly written, as I have yet to see a
fast configure. Beyond say the one for asspr.

-- 
William L. Thomson Jr.


pgp7QIqKdPlHt.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-24 Thread William L. Thomson Jr.

On Thu, 23 Nov 2017 16:36:07 +
Peter Stuge <pe...@stuge.se> wrote:
>
> It's arguably a bug that a projects gets huge.

Sometimes huge projects are split into many internally. Imagine this
was using autotools. I doubt it could use a master configure for all
sub projects, but maybe.
https://github.com/apache/incubator-netbeans

> The simplicity of configure+make is difficult to beat, but I also
> agree that it's difficult or at least tedious to master autotools.

The syntax is nasty, the files get big quick. But that is not my main
gripe with what I call as a suite autotools. Make is not so much of an
issue, but configure I absolutely  hate. I cannot understand why
systems get faster, yet configure seems to take the same amount of time
and is super slow.

On small projects configure can take longer than compile... Configure
is my main gripe against make/autotools. Plus all the other stuff,
auto-reconf, autogen, etc.

> That is arguably reason enough to choose meson, but I think I will
> stay with autotools for a while..

Its likely to remain for sometime. I am not on the meson bandwagon
entirely as I like cmake+cpack. But I am surprised how many projects
are migrating to meson. Seems to be the current trend, and a
considerable amount moving to meson.

Meson vs cmake configure is not that big of a difference. maybe like
make vs ninja. But Meson or Cmake vs configure, HUGE difference...
The larger the project, the slower configure can be.

-- 
William L. Thomson Jr.

Re: [gentoo-dev] Strip features via profile.bashrc

2017-11-19 Thread William L. Thomson Jr.

On Sun, 19 Nov 2017 22:27:26 -0500
Mike Gilbert <flop...@gentoo.org> wrote:
>
> FEATURES gets processed by portage too early for bashrc settings to
> have any effect.

Glad to have that confirmed, as that is what I experienced.
Feel like I was in this commercial...
https://www.ispot.tv/ad/wlDi/directv-head-bang

> I do not think there is any equivalent to /etc/portage/package.env
> that can be defined in profiles.

Great thanks for confirming!

> I do not see any existing bug asking for this enhancement, so you
> could probably file a new one.

Will do, though I haven't had much luck in my profiles features
request. Sets went no where quick... Maybe this will have better luck!
https://bugs.gentoo.org/638196

-- 
William L. Thomson Jr.

[gentoo-dev] Strip features via profile.bashrc

2017-11-19 Thread William L. Thomson Jr.

I am trying to replicate like /etc/portage/package.env type function.
For some packages I had FEATURES="-buildpkg". I cannot seem to
replicate this what so ever with profile.bashrc.

Not sure how via a profile in an overlay/tree, not /etc/portage, one
can add/remove features. I do not seem to have this problem with other
stuff. I_KNOW_WHAT_I_AM_DOING works for skipping pre-merge checks.
I am also able to add CFLAGS/CXXFLAGS. Which I noticed were being added
like 4 times, so I added in a phase check/hook.

https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/profiles/linux/amd64/profile.bashrc

For some reason I cannot seem to add or remove FEATURES. I can see them
in the shell. But they seem to have no effect. At least with regard to
buildpkg FEATURE.

phase: setup features: assume-digests binpkg-logs buildpkg ...
phase: setup features: assume-digests binpkg-logs buildpkg ...

In this case its removed, but still makes a binpkg.

phase: package features: assume-digests binpkg-logs
config-protect-if-modified ...

.Doesn't show but in my output there is a gap, 2 spaces
where it was. I can see the profile.bash being processed and doing its
thing.

I have tried export and set, neither have effect. Even when replaced
with -buildpkg. Seems like make.conf is sourced or something for that.
I do not think I am setting it to late. I cannot seem to set it for the
build env.

Any way to do this? A bug?

--
William L. Thomson Jr.

pgpBoa0TfVu_m.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-19 Thread William L. Thomson Jr.

On Sun, 19 Nov 2017 16:49:51 + (UTC)
Martin Vaeth <mar...@mvath.de> wrote:

> William L. Thomson Jr. <wlt...@o-sinc.com> wrote:
> >
> > case ${CMAKE_MAKEFILE_GENERATOR} in
> > emake)
> > DEPEND="sys-devel/make"
> > ;;
> > ninja)
> > DEPEND="dev-util/ninja"
> > ;;  
> 
> This is broken: Static metadata like DEPEND must not depend
> on dynamic data like environment variables which are supposed
> to change at emerge time.

I wondered about that. I guess adding to DEPEND via eclass is bad then.

> > Only 2 thus far does not sound like most things would have issues.  
> 
> In fact, almost nothing has issues.

That has been my experience why I brought it up.

>I am using
> CMAKE_MAKEFILE_GENERATOR=ninja in my make.conf
> since years, and the total list of packages which had
> ever failed here (out of currently ~1500 installed)
> is this:
> 
> dev-util/cmake
> kde-apps/kate
> kde-apps/gwenview
> media-libs/avidemux-core
> media-libs/avidemux-plugins
> media-video/avidemux
> media-video/kaffeine
> media-video/kmplayer
> net-vpn/kvpnc
> sci-mathematics/reduce
> 
> This list might appear long, but note that

That is not that long and seems to favor heavily in ninjas favor. Seems
considerably more have no issues with ninja than make.

Thanks for that information!

> > Ninja is most of the speed of meson less configure time savings  
> 
> ++
> For eix, the main motivation to support meson as an
> alternative build system was to be able to use ninja...

For new projects I do not want a deb or rpm I like meson +
ninja. For all other stuff I prefer cmake + ninja. Kinda best of both
worlds. At least till meson can spit out deb and rpm, not just rpm spec.

I also like how cmake updates po files. Not sure about pot file, meson
does have something there, and can update them. Just a separate
process. cmake updates po all the time, I like that :)

But either way meson or cmake, ninja is the main speed for compiling.
Though I do like the cmake make output formatting and color, etc.

-- 
William L. Thomson Jr.

pgpsyIoAkVBmh.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Java 9 on Gentoo

2017-11-18 Thread William L. Thomson Jr.

Eating spam for breakfast! Glorious Spam!
http://cdn.ipernity.com/142/50/59/32265059.4aebaf91.640.jpg
https://landof1words.files.wordpress.com/2013/03/sir-can-a-lot.jpg

On Sat, 18 Nov 2017 09:59:15 -0500
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
>
> That is also the main reason for Icedtea project existence beyond
> having a FOSS harness to build/boostrap OpenJDK/Java. Oracle JDK may
> only support certain archs. If you want to build on another, that is
> where Icedtea plays a role. Though again still have other issues,
> Hotspot, Zero, OpenJ9, legacy JamVM, etc. 

Ideally these are like USE flags, some are already for icedtea.

cacao, jamvm, and zero, in addition to default HotSpot.
https://en.wikipedia.org/wiki/List_of_Java_virtual_machines

No clue if icedtea/gnuandrew is looking to add support for OpenJ9. That
would likely be a big one since its from IBM, and the core to their JDK
for Power.

IBM also has a JDK, not packaged on Gentoo. Everyone already hates
Oracle so little interest in IBM. Ideally Gentoo should have it, though
not sure if it will continue on beyond 8. Maybe why they released J9.
It does support different archs.
https://www.ibm.com/developerworks/java/jdk/

-- 
William L. Thomson Jr.

pgp05SgGcZ0bA.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Java 9 on Gentoo

2017-11-18 Thread William L. Thomson Jr.

Forgot something useful

On Sat, 18 Nov 2017 09:50:51 -0500
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
> 
> Otherwise yes, unless icedtea-bin exist for that arch. Boostrapping
> in a post gcc-jdk/java 7 world will be difficult, If not impossible
> for some archs.

That is also the main reason for Icedtea project existence beyond having
a FOSS harness to build/boostrap OpenJDK/Java. Oracle JDK may only
support certain archs. If you want to build on another, that is where
Icedtea plays a role. Though again still have other issues, Hotspot,
Zero, OpenJ9, legacy JamVM, etc. 

Me personally I wish Oracle/Sun had kept JRockit as an alternative as
well. It was merged into HotSpot. Or released with Hotspot in OpenJDK
https://en.wikipedia.org/wiki/JRockit

Thus there is some reason for Icedtea project to exists beyond just
legal/licensing.

-- 
William L. Thomson Jr.

pgpdnh0ALbobn.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Java 9 on Gentoo

2017-11-18 Thread William L. Thomson Jr.

On Sat, 18 Nov 2017 14:11:11 +
Roy Bamford <neddyseag...@gentoo.org> wrote:
>
> You can start with gcc-5.4 with the gcj use flag.
> That will bootstrap icedtea:7
> icedtea:7 will bootstrap icedtea:8
> Tested on arm64.

Your likely one of the few to do that :)

That is good one does not have to go back to 1.5, and 1.6.. Not bad to
get to 1.8, but once 9 is out. Not much fun going from 7 to 8 to 9.
No real reason to do that unless you want to. Or don't trust
Chewi/James icedtea-bin. He does like to spy :P j/k

The main reason for icedtea/openjdk vs oracle is to build openjdk or
java with open source licenses. I think if you build against oracle
your accepting oracles license for their JDK. It does not really taint
the result. But does mean java was built with non FOSS software. Oracle
JDK is downloaded under a different license agreement.

Its mostly a legal thing, and there is some slightly better system
integration. Definitely if building from source. Still some using
icedtea-bin, but thats a binary. So not sure as deps it was built
against change, etc. From source is likely different there.
Though I haven't really ever had issues with Oracle and system
integration. Occasionally people will have fonts issues. Fonts tends to
be one of the most noticeable visual difference between Oracle and
Icedtea/OpenJDK

I do not mess with openjdk/icedtea much if at all. I mostly run with
Oracle for various reasons. Licensing is not a concern. I am used to
Java long before it was FOSS.

> With icedtea:7 going and gcc-5.4 not having a very long future,
> building icedtea for a new arch will be painful. 

The main problem with arch support is HotSpot. There is not many
replacements for other archs.
https://en.wikipedia.org/wiki/IcedTea#Platform_support

Not sure of OpenJ9 will change that. I think it will at min support
Power archs, ppc64 etc. Not sure about ppc 32bit.
 https://github.com/eclipse/openj9
https://github.com/ibmruntimes/openj9-openjdk-jdk9
https://bugs.gentoo.org/631156

Otherwise yes, unless icedtea-bin exist for that arch. Boostrapping
in a post gcc-jdk/java 7 world will be difficult, If not impossible for
some archs.

-- 
William L. Thomson Jr.

pgpNM3IqwfZI6.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Java 9 on Gentoo

On Sat, 18 Nov 2017 02:40:14 +
Peter Stuge <pe...@stuge.se> wrote:

> William L. Thomson Jr. wrote:
> > > If you have any suggestions as to what I should look at to better
> > > understand the OpenJDK build system I would very much appreciate
> > > them.  
> ..
> > Build OpenJDK stand alone. Get familiar with that.  
> 
> It used to be that one could not build OpenJDK without already having
> a working JDK. Has that changed with OpenJDK 9 (IIRC it was planned
> for OpenJDK 7 :) or not yet, and that is a reason for having icedtea
> in the mix?

Yes you are correct, nothing has changed there to my knowledge.

It has to bootstrap itself. No one goes all the way back to the
classpath 1.5 days, and boostraps up from pure source.
Build 1.5, then 1.6, then 1.7, then 1.8, etc...

Everyone at this point starts with some version of a working JDK
binary. Once icedtea-bins are were, those were used to build icedtea
from source.

If you want say icedtea you will see it pull in icedtea-bin. If you
want the latest, it will pull in the version older unless a -bin of the
latest exists. Which comes from  a working from source ebuild.
https://github.com/gentoo/java-overlay/blob/master/dev-java/icedtea/icedtea-3.7.0_pre00.ebuild#L139

Ideally there is also an openjdk ebuild that would build with either
icedtea-bin, or oracle-jdk-bin. Or could always add a open-jdk-bin like
the oracle one, and use it to build openjdk ebuild.

That is very complex. Even the icedtea from source ebuild is non
trivial. The only one who does major work there is the Icedtea author.
Which Gentoo luckily benefits from directly, but is not the intention.
That is their job at RedHat.

gnu_andrew in #gentoo-java (but please do not just bug him hes busy!)
https://www.linkedin.com/in/gnuandrew
https://github.com/gentoo/java-overlay/commits?author=gnu-andrew

-- 
William L. Thomson Jr.

pgpsEwKZXtTk7.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: cmake + ninja vs autotools

On Sat, 18 Nov 2017 02:52:33 +0100
Francesco Riosa <viv...@gmail.com> wrote:
>
> In my user opinion this has no place in a ebuild unless upstream
> clearly say to use (or evidently use) ninja as it main generator.

I think Gentoo deviates from upstreams fairly considerably at times. I
see this as case where Gentoo can help facility things to upstream.
Maybe they haven't the time to test, etc.

Current example
https://sourceforge.net/p/firebird/mailman/firebird-devel/thread/assp.04935012e0.20171116111219.18e86899%40wlt.obsidian-studios.com/#msg36117925

> In cases where ninja is considered (by upstream) the best option,
> Michael suggestion to make it overridable is a very wise one.
> In that case, please also remember to depend on ninja

I do not think that is necessary unless it bypasses this

case ${CMAKE_MAKEFILE_GENERATOR} in
emake)
DEPEND="sys-devel/make"
;;
ninja)
DEPEND="dev-util/ninja"
;;

> Since other emails (by Christoph and Brian) in this thread make
> evident that it's not a drop in replacement,  fixing it in the eclass
> seem a bad idea, but that probably should be reconsidered when ninja
> become more capable.

Only 2 thus far does not sound like most things would have issues.
Maybe worth a bug to track stuff that builds fine and things that fail.
Could use the math alone to make a final call. More packages fail,
stick with make. if only a few, switch to ninja and have those stick
with the slow make.

Either way up to others. I am just passing on whats going on in many
other FOSS projects. Ninja is most of the speed of meson less configure
time savings.

-- 
William L. Thomson Jr.

pgpbJ6TtMkfy0.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Java 9 on Gentoo

On Thu, 16 Nov 2017 23:41:53 -0500
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:

> On Thu, 16 Nov 2017 21:42:59 -0600
> Matthew Thode <prometheanf...@gentoo.org> wrote:
> >
> > You seem to know a bit about this, has there been a bug made
> > outlining the troubles we will encounter as you know them?  
> 
> No

A user did file a bug for Java 9. Which the response they received from
Gentoo discouraged them and they closed it. Nice
 https://bugs.gentoo.org/634698

IMHO no way to respond to a user. Their reaction is the exact reason
why. When others showed in #gentoo-java asking about 9. I first stated
I guess no one cares since no bug has been filed. To my surprise one
was, and it was closed due a rude response from Gentoo. They could have
not commented at all Bug would have remained open. Doubt that users
will return... Much less help out etc.

My response and attitude is because the only reason Java 9 was not in
tree zero day release, is because of Gentoo itself.
https://bugs.gentoo.org/634698#c5

I would have had it in log ago and maintained since. Much less discover
all the issues I am now and fixing them in tree vs overlay.
 Dec 5, 2016
https://github.com/Obsidian-StudiosInc/os-xtoo/commit/f90d8b21c39dbe8684e0951b845c43fae2ba6cfc#diff-0ecef02a46ed32d29b482614d71d229f
https://github.com/Obsidian-StudiosInc/os-xtoo/commits/master/dev-java/oracle-jdk-bin

Go GENTOO!

-- 
William L. Thomson Jr.

pgp7CKzVK3m2k.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Java 9 on Gentoo

On Fri, 17 Nov 2017 12:07:23 -0500
NP-Hardass <np-hard...@gentoo.org> wrote:

> Oh come on!
> 
> Triple posting to the ML?
> 
> Do we really need to have another discussion about not being spammy...
> Please... Think before you post...

Yes you should think before you post!

Every bit contains useful technical information. Maybe make some effort
to package or help JDK on Gentoo vs a pointless comment.

Like you said, THINK!

-- 
William L. Thomson Jr.

pgpNG4RcFvy0f.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Java 9 on Gentoo

On Fri, 17 Nov 2017 03:24:47 -0500
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
>
> The icedtea from source ebuild is a result of RedHat. The main person
> at RedHat responsible for their open source Java is the author of
> Icedtea. He uses Gentoo as his development/test platform. Gentoo
> usually will have that at least the same time as others, if not before
> all others.
> 
> If it was not for him, and RedHat paying him. I doubt Gentoo would
> have from source Java. Not to discount Chewi/James efforts. But the
> author of Icedtea is the one maintaining that in java-overlay.

Something to keep in mind. Part of why Icedtea lags like with Java 9.
The Icedtea author as part of their role at RedHat is responsible for
older versions as well. Much of their time is consumed in dealing with
older. Thus the latest does not always get as much time, or 100%.

Next month 1.6 ends, but with 9 out not sure it helps. Still has 1.7
and 1.8 for some time to come. They have to maintain 3 versions...
https://access.redhat.com/articles/1299013

-- 
William L. Thomson Jr.

pgp_rJ43UR3hN.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Java 9 on Gentoo

To really get crazy, another thing Gentoo likely won't see unless
someone steps up. OpenJ9  alternative to HotSpot.

https://en.wikipedia.org/wiki/OpenJ9
https://github.com/ibmruntimes/openj9-openjdk-jdk9
https://www.slideshare.net/DanHeidinga/j9-under-the-hood-of-the-next-open-source-jvm

-- 
William L. Thomson Jr.


pgpi7ZGgRFiQs.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Java 9 on Gentoo

ally ideal. Just lazy option.

> If I understand correctly, it is possible to install the JDK but not
> set it to system VM? It is not clear to me why other languages need
> more Portage machinery to handle coinstallation of different versions.

You can run stuff on Java 9. You will have problems with emerging or
building Java packages on Gentoo. Unless you are developing your own
application in Java. It is fine for development use. There are just
problems with merging other Java packages if 9 is set as your system vm.

You may experience problems running stuff on Java 9 as well.

-- 
William L. Thomson Jr.


pgpyv8ijkkDC9.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Java 9 on Gentoo

rete
> discussion on behavior to be addressed reflects poorly on those who
> sought disciplinary action.

The whole thing is a mess. Let me just say this, You DO NOT take action
against a recently resigned Trustee who stepped down mid term. Despite
within 6 months getting Gentoo a Bank Account, Legal again with New
Mexico (though never has had the same with IRS since Daniel), and a
public review of draft by laws such that they were adopted right after
I resigned. Which shortly after I was encouraged to retire.

Since then people have just been problems, standing in the way of
progress for no good reason. The world is fraught with social issues.
Technical projects are no means to solve them. Gentoo has suffered in
many ways, not just technically via Java, but also the work I was doing
on the Foundation.

I was paying close attention to FreeBSD then. It is interesting to see
where FreeBSD is now compared to Gentoo. One rose the other fell.
Gentoo is not the only project that suffers from such. Though it has
some unique things that have not helped it

> However, I am not a very smart man. I am usually wrong. Hopefully
> someone who is much more intelligent than I can explain how I have
> erred in my opinion.

Its wonderful to be wrong. We learn more, or should... :)

-- 
William L. Thomson Jr.

Re: [gentoo-dev] Java 9 on Gentoo

On Thu, 16 Nov 2017 21:42:59 -0600
Matthew Thode <prometheanf...@gentoo.org> wrote:
>
> You seem to know a bit about this, has there been a bug made outlining
> the troubles we will encounter as you know them?

No, I feel I am already doing more than I should to help given my past
treatment. I have been making most issues with potential resolutions
know in #gentoo-java for the past ~48 hours. I have been spending
most time fixing stuff in my overlay. As I have been for over a year.
https://github.com/Obsidian-StudiosInc/os-xtoo

>  It's nice to have a warning, but sounding alarmist without concrete
> help doesn't actually help all that much.

People have been asking in #gentoo-java about Java 9. I was simply
letting everyone know it would be some time before that is likely to be
the case. That alone was a courtesy to others.

It does not take much to find out there are considerable issues with
Java 9 from most any web search. For anyone who cares, most do not.
Thus the present state of Java on Gentoo. Which I have brought up many
times over the past years. A new major version taking some time should
not be of surprise to anyone given that fact.

If you recall I got banned from Github over commenting on Java 9 early
access PR. I have also commented on another since.
https://github.com/gentoo/gentoo/pull/1721
https://github.com/gentoo/gentoo/pull/6033

You can see the history of jdk 9 I put in my overlay almost a year ago.
That could have been in Gentoo. I maintained EA builds till release...
Dec 5, 2016
https://github.com/Obsidian-StudiosInc/os-xtoo/commit/f90d8b21c39dbe8684e0951b845c43fae2ba6cfc#diff-0ecef02a46ed32d29b482614d71d229f
https://github.com/Obsidian-StudiosInc/os-xtoo/commits/master/dev-java/oracle-jdk-bin

I have done all I can. This is the visible result of blocking people,
with no one else wiling to do the work. I am playing catch up now.

-- 
William L. Thomson Jr.

pgpDnE5BlR_1f.pgp
Description: OpenPGP digital signature

[gentoo-dev] Java 9 on Gentoo

Just as a heads up, pass it along. For anyone interested. It will be
some time before Java 9 is available on Gentoo. It will take
considerable work to get it unmasked and safe for use.

Once in tree masked, it will likely be very painful for anyone who does
unmask. You have been forewarned!!!

NOT FUD!
Constructive heads up as to the factual state of things. If
you would like to see them change. Talk to Chewi/James Le Cuirot. He
will need lots of help! Even with others I guestimate a month or more
before it can be unmasked. Once its added to tree...

-- 
William L. Thomson Jr.


pgpyjGgp4pQab.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] cmake + ninja vs autotools

On Thu, 16 Nov 2017 09:17:52 -0700
Christoph Junghans <jungh...@gentoo.org> wrote:
>
> > Ninja doesn't support Fortran as well.  
> Besides not supporting the full feature set.

That does not seem to be effecting meson. Which only supports ninja.
A considerable amount of projects are switching to meson, look around.
I have switched over a couple projects I am working on. I have worked
with all three, autotools, cmake, and meson. I prefer cmake + ninja.

The performance  of meson vs cmake is negligible. Given cmake cpack, I
prefer that for now over meson. I could not make a strong case for
speed of cmake vs meson. That is moot speed wise, pretty equal. Meson
maybe a tad faster.

> Ninja vs make didn't seem to make big time difference (for cmake at
> least). Back in 2013 ago only found a 40sec difference (of an 6.5 min
> overall build) when building kdelibs averaging over 3 builds, which
> had more than 40s scatter in the individual builds.

It is making huge differences in other projects. I have seen
considerable time savings in the smaller projects I am working on,
ecrire, entrance, clipboard, and some others.

Enlightenment desktop for 0.23 release will have dropped autotools
entirely for meson. 0.22 already ships with meson. I switched over and
it builds faster. No problems there with ninja. I think EFL may switch
to meson as well. Other E projects like rage have already.

> That coincides with my own experience outside of portage where ninja
> and make are pretty much even for a full build, but ninja is much
> faster in figuring out which parts to rebuild in a partial build.

Maybe time to check again. My experience says otherwise. I can switch
over some stuff in travis and show via CI the difference in time. I see
it all the time in development doing routine builds as part of code,
build, test, code, etc. Rinse and repeat.

-- 
William L. Thomson Jr.

pgpaAQR5qEBTJ.pgp
Description: OpenPGP digital signature

[gentoo-dev] cmake + ninja vs autotools

It maybe worth considering switching the default generator in the
cmake-utils.eclass from the default of emake to ninja.

- : ${CMAKE_MAKEFILE_GENERATOR:=emake}
+ : ${CMAKE_MAKEFILE_GENERATOR:=ninja}

For those with cmake ebuilds you can test this out now via 

CMAKE_MAKEFILE_GENERATOR="ninja"
inherit cmake-utils

Working with both cmake and meson. It seems the real performance of
meson comes from ninja. I am a bit more a fan of cmake than meson for
cpack, generation of deb, rpm, and binary tarball, in addition to
sources. That can be done with meson but not as elegantly at this time.

ninja is noticeably faster than make. I haven't seen any cases yet where
cmake autotools works, and ninja does not. They seem pretty equal, so
should be safe. Of course could use testing first.

Again something to consider. Myself I am avoiding autotools anywhere I
can, mostly because of the slow configure and also slow make. Anytime I
use cmake, I am using ninja generator.

-- 
William L. Thomson Jr.


pgpp2umjxeef0.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] manifest-hashes changing to 'BLAKE2B SHA512' on 2017-11-21

On Wed, 15 Nov 2017 17:10:11 -0500
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
>
> Like FreeBSD Foundation, a real organization paying for development
> via grants and other things...
> https://www.freebsdfoundation.org/
> https://www.freebsdfoundation.org/what-we-do/grants/
> 
> https://www.freebsdfoundation.org/wp-content/uploads/2015/12/2017-Q2-Profit-Loss.pdf

For the record, FreeBSD was not like that long ago when Gentoo/we had
booths near them at Linux World Expo. Most of that has happened since.

" A budget of $80,000 was allocated for 2008 to fund multiple
development projects." 
https://www.freebsd.org/news/2008/index.html

https://www.freebsdfoundation.org/wp-content/uploads/2015/12/Budget2011.pdf

-- 
William L. Thomson Jr.


pgpx4myn7oQvo.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] manifest-hashes changing to 'BLAKE2B SHA512' on 2017-11-21

On Wed, 15 Nov 2017 16:15:18 -0500
Rich Freeman <ri...@gentoo.org> wrote:

> On Wed, Nov 15, 2017 at 3:21 PM, William L. Thomson Jr.
> <wlt...@o-sinc.com> wrote:
> >
> > The council has no power
> > over Trustees, and Trustees do have legal power over all of
> > Gentoo.  
> 
> Sure, just keep in mind that legally Gentoo is basically nothing but a
> name and a logo.

That is what others have made it to be. It was never intended to be
such by the person who created the foundation in the first place.
Paying for those legal filings and attorney fees out of pocket! The
only time any proper IRS filings was done for Gentoo
I have showed in -project what it was supposed to be.
https://archives.gentoo.org/gentoo-project/message/3ac5418dd061fc53f4b8d55a99773f4c

Like FreeBSD Foundation, a real organization paying for development
via grants and other things...
https://www.freebsdfoundation.org/
https://www.freebsdfoundation.org/what-we-do/grants/

https://www.freebsdfoundation.org/wp-content/uploads/2015/12/2017-Q2-Profit-Loss.pdf

Presently working on raising $1.25 Million USD for next year.
Look at the donors on their home page. Intel, Netapp, Versign, Netflix
even Microsoft...

Gentoo is missing out big time! But it is the communities choice. If
Gentoo is just a name and logo, that is pretty sad
Limited vision

-- 
William L. Thomson Jr.

pgp0ONUuZb1Gt.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] manifest-hashes changing to 'BLAKE2B SHA512' on 2017-11-21

On Wed, 15 Nov 2017 14:21:59 -0500
NP-Hardass <np-hard...@gentoo.org> wrote:
>
> 
> No, if you think there is an issue with the Council decision, you
> should speak with the Council.  Moreover... The Council is
> responsible for technical decisions within Gentoo.  Unless it
> violates the Social Contract, I cannot see how the Trustees should be
> involved here.  They have empowered the Council to make technical
> decisions as they see fit.

There is nothing empowering the Council from the Trustees. Legally the
Trustees could have final say. The Council is not a legal body nor
formal in any legal filing. They have no say when it comes down to it
from a legal perspective.

However everything is structured such that the Council does have final
say over all technical matters. That is something the community
did, and adheres to. There is nothing, to my recollection, in Foundation
By Laws or other that would connect the two. The council has no power
over Trustees, and Trustees do have legal power over all of Gentoo.

The Trustees just abstain from technical matters, as that is the
structure the community has accepted. I am not aware of anything else
with such structure.

Nothing legally gives Council final say technically. That is just how
things are, and likely will always remain as such. Which is some what
strange as Trustees can be responsible for the actions of others.
Despite having no say in such matters till it becomes a legal issue.

IMHO I rather see a structure where Council is more like CTO. Still top
for technical, but falls under Trustees for oversight, final say, etc.
A normal structure like exists in most any business globally. They
should work together more as one vs two bodies.

-- 
William L. Thomson Jr.

pgplVlLDTr5OY.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] manifest-hashes changing to 'BLAKE2B SHA512' on 2017-11-21

On Wed, 15 Nov 2017 11:47:41 -0600
R0b0t1 <r03...@gmail.com> wrote:
.> 
> Does the existence of a decision mean I would need to contact the
> trustees if I feel the changes have not been adequately justified?

They have no power here. Consider the foundation as second head of a 2
headed snake. Used to be 3 when infra was more powerful. Trustees maybe
could if there was a different structure. But the foundations role is
pretty limited and intentionally crippled.

Unless you can provide a compelling legal case that would fall under
the legal protection duties of the trustees. But in general Trustees
cannot dictate to council, its the other way around. Council dictates
to Trustees. I doubt it will ever change. I tried long ago.

Council has final say on all technical matters unless it involves
legalities.

-- 
William L. Thomson Jr.

pgprHXOabiLOc.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Server hardaware give away (misc archs)

2017-09-09 Thread William L. Thomson Jr.

On Sat, 9 Sep 2017 11:45:23 +0800 (HKT)
Brendan Horan <bren...@horan.hk> wrote:
> 
> Its all well and good to ask, I don't mind.
> However systems like this need good , caring owners not a
> "board/trust " group. I don't mean that in a disrespecting way.
> They just need a little more attention and up keep.

FYI, it becomes the responsibility of Gentoo Infra not the
Trustees/Foundation. The board would just facilitate any financial and
legal/customs. Once the equipment is under Gentoo control. It is handed
off to infra. Infra maintains the server, controls where it is hosted
at, etc. They should be able to "take care" of the equipment.

I would not be concerned with Infra caring for the any hardware.
Physical stuff would be up to the hosting provider. Making sure its not
on fire, or other.

-- 
William L. Thomson Jr.

pgpHNETht1NDX.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Categories for GUI stuff x11 and wayland

2017-09-08 Thread William L. Thomson Jr.

On Wed, 30 Aug 2017 14:01:08 -0400
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:

> This is more food for thought to start a discussion on new category
> names. With Wayland becoming more of a reality every day. I think some
> of the x11-* categories may need to change. Stuff in there may not be
> bound to X and can run on Wayland or X.
> 
> Examples
> x11-libs/gtk+
> x11-terms/terminology
> 
> Not sure what better "universal" category names would be. But seems it
> maybe time for a discussion on such and some new categories and
> package moves. Given thus stuff can run under X or Wayland. Not sure
> x11 makes sense anymore.

One thing I forgot to mention, the x11-* would not go away just shrink.

General stuff that is for say X11 or Wayland would go into the "new"
categories. Anything that is X specific, like xorg, drivers, xephyr, etc
would remain in the location and category it presently resides.

This would reduce the amount of package moves, but still would be fair
amount. With some being pretty major like moving GTK+. EFL ended up in
dev-libs, and I am not sure if that is the proper location, though it
does cross many categories. GTK+ and  FLTK are in x11-libs. I think EFL
ended up in dev-libs due to Wayland situation.

P.S.
I myself am not super excited about wayland. I see reliving a lot of
the problems of the past. Not to mention wayland supporting what X can
do now, today. Many things still in the works for most any
supporting Wayland, dual display, different resolutions etc. I gave it
a nickname  "Waitland" as you have to WAIT for wayland to support this
or that Either way it seems inevitable... Even if years off from
being the daily driver.

-- 
William L. Thomson Jr.

pgp3CaqGR0WTn.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Server hardaware give away (misc archs)

On Thu, 7 Sep 2017 07:44:00 -0700
Rich Freeman <ri...@gentoo.org> wrote:
>
> In general I would just comment that if anything we get too few
> requests for spending money and not too many. 

Not surprising, though I had ideas on lots of spending, events, travel
reimbursement, developer systems, etc.

> I don't think the  Foundation would be able to just go buying PCs for
> every dev on request, but for one-offs like these they might chip in.

More like the Foundation/Gentoo should have some plan and/or budget as
to how to put the funds to use etc. Which gives others reasons to
donate more when they can see where the funds are being used, the
benefit etc.

Example
https://www.freebsdfoundation.org/wp-content/uploads/2015/12/Budget2016.pdf

> One thing that should be considered in these sorts of requests is who
> owns the hardware and where it will be kept and what kind of access
> other devs on the relevant teams would have.  I think there ought to
> be a difference between how we treat hardware that is owned by the
> Foundation and always available to devs, vs something that somebody
> intends to use for Gentoo work right now, but where ownership resides
> with the individual and there is no obligation to give the hardware to
> somebody else if they stop contributing.  To the extent that the costs
> are more nominal the Foundation should probably exercise more leeway.

In an ideal sense, equipment like this would go to something like OSU
OSL or some other hosting provider. Though there is the cost of
bandwidth, power, and man power to service hardware issues. Not to
mention rack, provision, etc.

Donate gear to Gentoo to be used/accessed by any dev, and maybe some
others. I think Gentoo should have more internal resources available
for developers to use. Then again I had lots of ideas for Gentoo

-- 
William L. Thomson Jr.

pgpERLkDydGS8.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Server hardaware give away (misc archs)

On Thu, 7 Sep 2017 10:26:10 -0400
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:

> On Thu, 7 Sep 2017 18:03:21 +0800 (HKT)
> Brendan Horan <bren...@horan.hk> wrote:
> 
> > Just an update for everyone :
> > R0b0t1, has the Power 6+
> > Johnson, has the Sparc T5120
> > 
> > Still working out shipping/logistics   
> 
> If someone has access to say a company UPS or FedEx account. They may
> have discounted rates based on volume.  Maybe something to consider or
> look into. Also may help with customs to ship to a work/business
> address and/or coming from one business to another vs individuals.
> 

Another thought

Why not have Gentoo Foundation cover shipping costs?
What else is Gentoo doing with its $100k to help further development?

May want to go talk to Trustees. This seems like a legit use of funds.

-- 
William L. Thomson Jr.


pgpNuyHNmydxP.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] sys-boot/grub:0 (GRUB legacy) sunset planning

On Sat, 2 Sep 2017 15:56:04 +
"Robin H. Johnson" <robb...@gentoo.org> wrote:

> Open questions:
> --
> - Are there existing use cases that I've missed, where migration to
>   grub-2 CANNOT be done?

I left grub sometime ago for syslinux/pxelinux/extlinux. I run that on
everything now even UEFI. I much prefer it to grub. That maybe an
option for grub:0 users, who cannot or do not want to use grub:2.

I had issues with grub pxe hardware support. Given that you tend to
use syslinux on like usb and  iso's. I just stick to one for all.

-- 
William L. Thomson Jr.

pgpovGHqHz3LI.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Server hardaware give away (misc archs)

On Thu, 7 Sep 2017 18:03:21 +0800 (HKT)
Brendan Horan <bren...@horan.hk> wrote:

> Just an update for everyone :
> R0b0t1, has the Power 6+
> Johnson, has the Sparc T5120
> 
> Still working out shipping/logistics 

If someone has access to say a company UPS or FedEx account. They may
have discounted rates based on volume.  Maybe something to consider or
look into. Also may help with customs to ship to a work/business
address and/or coming from one business to another vs individuals.

-- 
William L. Thomson Jr.

Re: [gentoo-dev] Re: Categories for GUI stuff x11 and wayland

2017-09-04 Thread William L. Thomson Jr.

The points made about both ux- and gui- make sense. As does using
something like desktop- which could be confusing for mobile, wearable,
or other stuff with graphics. Not sure if length is of concern.

One that is in use now that has not come up is gfx. That is used now
for like media-gfx. Not sure if it would be confusing to have its own
category

gfx-libs
gfx-tools
gfx-apps

Though gfx and gui are pretty much the same. Given that there is a
wikipedia page for GUI. gui-* may be the most clear to all.
https://en.wikipedia.org/wiki/Graphical_user_interface

Maybe just UI but that maybe to generic.
https://en.wikipedia.org/wiki/User_interface

The wikipedia page on UX would make it not suitable
https://en.wikipedia.org/wiki/User_experience

-- 
William L. Thomson Jr.


pgpwgGUX4N5zM.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Categories for GUI stuff x11 and wayland

2017-08-30 Thread William L. Thomson Jr.

On Wed, 30 Aug 2017 19:37:09 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
>
> That could be a lot of package-move churn.  It arguably might make
> sense to keep the current names "for legacy reasons".  (Or not.  Just 
> speculating here.)

For sure it would require touching lots of packages. Its not really a
minor thing, thus bring it up for discussion. Likely need to take into
consideration sooner than later.

For any new packages, likely best they go into proper new categories
then continuing on the legacy. Then it becomes a matter of what to do
for others. Lots of packages moves would not be fun.

Though something similar was done recently with vpn packages.

> FWIW, there was some related discussion awhile back on USE=X,
> proposing USE=gui instead, but I don't know what became of it.
> Perhaps gui-* category names if that's actually moving forward, in
> ordered to maintain a bit of consistency and for lack of a better
> idea? 

I think that is different as you do need X now to differentiate between
say X and Wayland. If it was just generic stuff then GUI would make
sense. Though usually other stuff handles that, gtk, qt, etc USE flag.

-- 
William L. Thomson Jr.

pgpcX67WTgfg_.pgp
Description: OpenPGP digital signature

[gentoo-dev] Categories for GUI stuff x11 and wayland

2017-08-30 Thread William L. Thomson Jr.

This is more food for thought to start a discussion on new category
names. With Wayland becoming more of a reality every day. I think some
of the x11-* categories may need to change. Stuff in there may not be
bound to X and can run on Wayland or X.

Examples
x11-libs/gtk+
x11-terms/terminology

Not sure what better "universal" category names would be. But seems it
maybe time for a discussion on such and some new categories and package
moves. Given thus stuff can run under X or Wayland. Not sure x11 makes
sense anymore.

I can do this on my own in my own overlay. But likely best for official
categories as this effects the tree not just others overlays etc. I do
not really have any ideas for better names. Just seems like a need.

-- 
William L. Thomson Jr.


pgpi3R6nIrlZr.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: app-benchmarks/jmeter, java-virtuals/javamail, dev-java/{gnu-classpath-inetlib,gnu-javamail,sun-javamail}

2017-08-29 Thread William L. Thomson Jr.

On Tue, 29 Aug 2017 23:40:11 +0100
James Le Cuirot <ch...@gentoo.org> wrote:

>
> > Both the same as sun-javamail and since renamed to just javamail.
> > Final name change
> > https://github.com/javaee/javamail  
> 
> Thanks for that. We started this ball rolling a while ago so I should
> have checked the current situation. This is getting a bit ridiculous
> but hopefully this really is the final time. I'll add javax-mail to
> the list and see if we can handle oracle-javamail -> javamail as a
> package move.

It should be, Oracle kicked most all foss stuff to Github, and shut
down java.net. The good news most all stuff is now under one location.
https://github.com/javaee

I know this was not ideal. The learning less is to not rename packages
per upstream. Per IRC seems it may have been dev-javamail long ago...
Time to break out some bell bottoms...

-- 
William L. Thomson Jr.

pgpmX3Q2_QI3A.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: app-benchmarks/jmeter, java-virtuals/javamail, dev-java/{gnu-classpath-inetlib,gnu-javamail,sun-javamail}

2017-08-29 Thread William L. Thomson Jr.

On Tue, 29 Aug 2017 22:35:25 +0100
James Le Cuirot <ch...@gentoo.org> wrote:

> # James Le Cuirot <ch...@gentoo.org> (29 Aug 2017)
> # The FOSS-friendly oracle-javamail has rendered other implementations
> # and the virtual obsolete. Removal in 30 days. See bug #553186.
> dev-java/gnu-classpath-inetlib
> dev-java/gnu-javamail
> dev-java/sun-javamail
> java-virtuals/javamail

Oracle javamail is no more, so need to add a couple more

+dev-java/oracle-javamail
+dev-java/javax-mail (duplicate package added by mistake)

Both the same as sun-javamail and since renamed to just javamail.
Final name change
https://github.com/javaee/javamail

-- 
William L. Thomson Jr.


pgp3aRWjNyB8y.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

On Mon, 14 Aug 2017 15:20:26 -0700
Rich Freeman <ri...@gentoo.org> wrote:

> On Mon, Aug 14, 2017 at 5:26 PM, William L. Thomson Jr.
> <wlt...@o-sinc.com> wrote:
> >
> > Portage supports sets, but the PMS has no mention. Then there is
> > debate on what they are. Creating so much noise it drowns the bug
> > request and makes it invalid. Despite the need still existing, and
> > PMS lacking anything on  sets.
> > https://bugs.gentoo.org/show_bug.cgi?id=624300
> >
> > Just the needs I have with portage are stalled, marked as invalid.
> > No discussion for inclusion in PMS. Like documenting sets.  
> 
> Ah, well, that's the main mystery of this thread solved.  Thanks.

That is the tip of the iceberg, not the main problem itself. I have
never been a fan of EAPI, or the resulting PMS, etc. Having been around
before such existed, I do not believe it has helped Gentoo and in fact
maybe the opposite. Why EAPI 0 stuff is in tree, or very old EAPIs.

Now becoming more real issues rather than just a dislike of EAPI.

-- 
William L. Thomson Jr.

pgp6MU9gw57_o.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

On Sat, 12 Aug 2017 09:55:02 -0500
Gordon Pettey <petteyg...@gmail.com> wrote:

> On Sat, Aug 12, 2017 at 9:50 AM, Alexander Berntsen
> <berna...@gentoo.org> wrote:
> 
> > While the PMS perhaps hasn't been an unequivocal success, it's
> > still a good effort with some success. I would be disappointed to
> > see the proposed change, and view it as a bad sign for Gentoo.
> >
> 
> Also, how many Portages are there that need to be managed with a
> "Portage Manager"?

If your asking about alternative package managers, I am aware of 2

paludis - requires heavy modification to environment
pkgcore - does not support EAPI 6, only experimental EAPI 5

pkgcore existed before PMS, and seems like more development before PMS
https://github.com/pkgcore/pkgcore/graphs/contributors

IMHO PMS was mostly about paludis and not Gentoo or portage. I recall
how it came about and the people behind the effort.
~2007-02-09
http://marc.info/?l=gentoo-dev=2=86=pms=b


https://wiki.gentoo.org/wiki/Paludis
https://wiki.gentoo.org/wiki/Pkgcore

-- 
William L. Thomson Jr.


pgpC_HOaicpMw.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

On Mon, 14 Aug 2017 15:09:15 -0400
Rich Freeman <ri...@gentoo.org> wrote:

> On Mon, Aug 14, 2017 at 2:42 PM, Peter Stuge <pe...@stuge.se> wrote:
> >
> > I am sure
> > that portage developers gnash their teeth at blockers stemming from
> > PMS, but I wholeheartedly believe that Gentoo, PMS and Portage are
> > all better off for it.
> >  
> 
> Honestly, I've yet to see any portage developers complaining about
> PMS here.

There are not that many, the core ones tend to do most the work
https://github.com/gentoo/portage/graphs/contributors

But I do not seem them participating here much.
https://gitweb.gentoo.org/proj/pms.git/

Also not sure that is mirrored to Github for what ever reason. To major
flags, no mirror to github, and little to no involvement from core
portage developers. That seems like a disconnect there.

Why would it not be mirred to Github? Not wanting outside PRs or input
on PMS?

> In general the main hoops to jump through if you want something in
> PMS are:

From a developer perspective, jumping through hoops will limit
creativity, and if nothing else hold back development. I tend to prefer
to keep development more unrestrained.

> Usually when #1 ends up being the hangup there tend to be serious
> concerns about how the concept will work in reality.  If it will make
> ebuilds harder to maintain or their behavior less predictable then an
> implementation alone isn't enough.  Either that or there are concerns
> that the design doesn't fully address the need, which often happens
> when we add a new dependency type.

Portage supports sets, but the PMS has no mention. Then there is debate
on what they are. Creating so much noise it drowns the bug request and
makes it invalid. Despite the need still existing, and PMS lacking
anything on  sets. 
https://bugs.gentoo.org/show_bug.cgi?id=624300

> IMO the process isn't really broken, and I doubt that changing the
> name would change anything.  We don't wait for other package managers
> to support a new PMS version before using it in the tree. 

More like package managers cannot add features not mentioned by PMS.

> We do value
> the input of anybody with expertise in this area, though the Council
> holds the final say.  PMS has a huge impact on our QA and I think
> we're generally better off for the time spent on it.

PMS I do not see as related to QA. It is something for other package
managers. I fail to see how PMS makes QA better. If anything repoman
makes QA better. I would have to double check but I bet many things
repoman looks out for is not in PMS.

> If somebody actually does have a PMS proposal that has been stalled it
> wouldn't hurt to share it, or if the portage team feels otherwise. 

Just the needs I have with portage are stalled, marked as invalid. No
discussion for inclusion in PMS. Like documenting sets.

-- 
William L. Thomson Jr.

pgpdVWo2WTAJB.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

On Mon, 14 Aug 2017 18:42:21 +
Peter Stuge <pe...@stuge.se> wrote:

> Alexander Berntsen wrote:
> > While the PMS perhaps hasn't been an unequivocal success, it's
> > still a good effort with some success. I would be disappointed to
> > see the proposed change, and view it as a bad sign for Gentoo.  
> 
> As far as technical documentation about how ebuilds work (the core of
> Gentoo, but also many other distributions; I have created several of
> my own), PMS is an absolutely amazing document!

I was not suggesting to get rid of it. Said another way,
What is the reference implementation of PMS?

Java has lots of specs, and usually a reference implementation. In the
case where there is no implementation is where companies compete. Thus
would not be in any benefit to assist the other with an implementation.

> It comes down to whether Gentoo is a "meta-distribution" with
> absolutely amazing generic tooling (including portage), or "simply" a
> source-based distribution with an arbitrary package format.

I am suggesting Gentoo be the reference implementation, portage be the
reference implementation of PMS. It should be limited by the developers
not outsiders.

I cannot explain why those who do portage development are not the PMS
authors. As a developer, it seems something is off there.

> PMS has tremendous value, and yes, EAPI is a process, and I am sure
> that portage developers gnash their teeth at blockers stemming from
> PMS, but I wholeheartedly believe that Gentoo, PMS and Portage are
> all better off for it.

EAPI is surely a process, I came across a EAPI=2 ebuild the other day,
and still likely some EAPI=0 in tree. I would not consider EAPI to be a
success by any means.

It creates waves of "wheel spinning". Revising the internals of an
ebuild for little to no gain. If I updated that EAPI=2 ebuild. The
installed result would be no different. Given that fact, I see no
benefit to EAPI=6 over EAPI=2.

> Without knowing specifics I guess I would suggest to the original
> poster to create new tooling for the job that needs to be done. Maybe
> even a fork of portage, at first only used in your (derivative)
> Gentoo distribution? Just my idea for a possible solution.

I am not using a derived distributions. I am running Gentoo with a
massive overlay due to the amount of packages not updated in tree.

My overlay would not exist if I could have returned. I cannot improve
from within thus I am limited to an overlay on top. But I am not
running some other distro or making my own.

I have warm and open offers to be part of Funtoo. None of my systems
run that. All my systems, servers and workstations run Gentoo. Just
with a massive overlay slapped on top.

-- 
William L. Thomson Jr.

pgp8OlFj5Nxey.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Revisions for USE flag changes

On Sun, 13 Aug 2017 12:12:39 -0400
Michael Orlitzky <m...@gentoo.org> wrote:

> On 08/13/2017 12:06 PM, William Hubbs wrote:
> > 
> > There is a down side you didn't talk about -- more work for the arch
> > teams and for us in terms of stabilizations.
> > 
> > When we revbump, a new revision automatically gets ~ keywords on
> > all arches unless we make an exception. If a revision changes iuse
> > but could still be built with the stable tree, I would want to be
> > able to commit this type of revision  directly to stable.
> >   
> 
> I don't think you should be adding features and code to stable ebuilds
> in the first place, but if you're going to do it, then I wouldn't let
> a little -r1 on the end of the filename stop you =P

I agree stable ebuilds should not be modified. What William Hubbs is
talking about is the work it creates on others. Which I am not sure can
be avoided as things are now with stablization process and policies.

Change IUSE of stable package. It becomes ~arch. Then it has to wait
~30 days to go stable. Which means it requires a arch tester, and then
someone to clean the old version before the IUSE change. That is the
extra work.

I think the difference is the package maybe using a stable tree, but
the change may cause the package itself to be unstable. Therefore
should go through the normal stabilization process. Despite being
stable before revbump. Not so much the env but the package itself.

P.S.
For my own reasons in my overlay I will skip a revbump at times when
making changes to an ebuild. But that is me doing stuff in my own repo
and with few users of my overlay. I know it is not the proper work flow.
Just cutting corners to save time.

My main reason to avoid is not lazyiness, as it is issues with my
ebuild-bumper. It does not handle -r*. If I am bumping a series of
packages with version A, to version B, if one has -r1 it requires
special attention. This is a personal thing in a personal overlay
outside of Gentoo. It would not be proper within Gentoo repos.

-- 
William L. Thomson Jr.

pgpG9KDKG46K6.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Revisions for USE flag changes

On Fri, 11 Aug 2017 19:50:14 -0400
Michael Orlitzky <m...@gentoo.org> wrote:

> We have a pull request for the devmanual that will update the revision
> documentation; namely, when to create a new one:
> 
>   https://github.com/gentoo/devmanual.gentoo.org/pull/67
> 
> The comments bring up an issue that I think can benefit from some
> hindsight. Specifically, the PR says that it's OK to change IUSE
> without creating a revision, because users can use --changed-use to
> catch it. My immediate objection to that was that --changed-use is
> specific to Portage, but let's reflect on the status quo.

The simple rule of thumb from way back when on revisions. If anything
on disk changes, then you should do a revision bump.

IUSE flag changes would in likely several ways change what is
installed. If nothing else the package database in /var/db/pkg would
change. Thus merits a revision bump.


-- 
William L. Thomson Jr.


pgp6crcF7gWA4.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Prevent binary/non-compiled packages from binary package creation

2017-08-10 Thread William L. Thomson Jr.

On Thu, 10 Aug 2017 23:30:37 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:

> Meanwhile, having buildpkg on virtual packages[1] is what amuses me.  
> There, most of the benefits of binpkgs that arguably apply even to 
> prebuilt binary and no-bin packages as long as they package and
> install /some/ file, arguably don't apply at all, tho I suppose there
> might be corner cases where they /could/.  

That is two other cases I did not think of, thanks for mentioning.

 - virtual ebuilds
 - meta ebuilds

binpkgs of those do not make much sense.

-- 
William L. Thomson Jr.


pgpW3MWkLSLmw.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-10 Thread William L. Thomson Jr.

On Thu, 10 Aug 2017 13:33:54 +1000
"Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:
>
> This is no greater risk than syncing from a potentially compromised
> mirror. You would use a mirror you trust and, similarly (perhaps even
> more so) you would use a binhost you trust.

Getting a bit ridiculous now. Let me get my tin foil hat.

So your suggesting Gentoo mirrors are could be compromised? Your saying
that Gentoo repo gets compromised. Which then leaks out onto mirrors. If
a mirror is compromised, clearly it would not match up to other mirrors
or the master Gentoo repo. All with no one in the world noticing. Not a
likely scenario.

Lets go down this rabbit hole. Lets say Gentoo repo was compromised.
You simply look at upstream sources and their hashes. If Gentoo
mirrored sources do not match up to upstream. Then you know something
is wrong.

Thus you have many ways to verify, pull from mirror, compare to mirror,
compared to master Gentoo repo, compare to upstream. None of that can
be done with a binpkg. There are no public binhost. There is no
official Gentoo binhost. That is something people setup.

They may trust their own binhost. But to imply that is more trust
worthy than public stuff that is in more than one verifiable location
against 3rd parties. That logic does not hold up.

> It does raise the idea of some form of signing of the Packages file,
> similar to gpg-signed portage snapshots, but that's moving well beyond
> the scope of this thread.

That still would never give you any 3rd party verification. Why do we
not self sign certificates? Why are those not trusted? Trust tends to
come from 3rd parties.

Even GPG relies on a WOT, without that its pointless. An unsigned GPG
key is pretty worthless. Signing stuff with that means nothing.

-- 
William L. Thomson Jr.

pgpcIWBAlyNQk.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

On Thu, 10 Aug 2017 11:25:34 +1000
"Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:

> On 09/08/17 10:43, William L. Thomson Jr. wrote:
> > Also your redistributing another's package
> > in binary format which may not be legally allowed.  
> 
> Just to clarify, I wasn't suggesting redistributing license-encumbered
> packages. Since binary packages are managed by the system
> administrator, not Gentoo (as a distro), it remains with the
> administrator to adhere to any relevant license restrictions. Plus
> the package manager can't tell if you're distributing binaries or not.

Sure, I was just pointing out that there maybe legal needs to prevent
such. Unless someone wants to circumvent. Their call but not default.

The package manager knows about fetch restricted ebuilds. It should
not to re-package that stuff. IMHO

-- 
William L. Thomson Jr.


pgpfMvLJegYBY.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

On Thu, 10 Aug 2017 10:50:45 +1000
"Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:

> On 10/08/17 06:35, William L. Thomson Jr. wrote:
> > FYI binpkgs have no hash. If someone did something malicious within
> > the binhost to the binpkgs. You have no way of knowing. Yes the
> > same can happen with ebuilds and manifest. But easy to sync portage
> > and see if a manifest has changed.  
> 
> This isn't exactly true - see ${PKGDIR}/Packages on the binhost, which
> is a manifest of built packages and related metadata. Granted this is
> created by the binhost, it does exist and contains SHA1 and MD5
> hashes, as well as package size. In that sense it's no different to
> how a package Manifest file works within a repository.

You are correct. I meant to say no verifiable hash. You can hash
anything locally and claim it to be trustworthy. Thus mentioning
syncing portage to compare manifest of ebuild/SRC_URI.

Someone remakes a binpkg tarball, edits ${PKGDIR}/Packages with new
SHA1 and MD5. No way to know.

IMHO SRI_URI is more trustworthy than binhost, in the sense of
verification. If  you have means to verify the binhost stuff it maybe
more trustworthy. That is left to the admin.

I see binpkg as a temporary convenience. I am doing updates across many
of the same systems. Less images, containers, etc. I made binaries on
one system. Immediately used as updated on others. Then discarded on
binhost. Also used for  testing, reverting between slotted versions.

-- 
William L. Thomson Jr.

pgpo6yopgjta1.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

Just to clarify, the contenders for no binpkg would be the
following, potentially more.

 - ebuilds that are fetch restricted
 - ebuilds that installs files unchanged, like kernel sources
 - Binary ebuilds, -bin, that just use src_install and do not build
   anything

There may be some other cases, but I think that covers the main ones.
The first case, should NEVER, not even optionally be allowed to be
binpkg. That is re-distributing something that is fetch restricted. If
it cannot be mirrored, I doubt it can legally be  re-packaged.

The later 2 could be "optional" defaulted to not build, but could be
forced. There is little benefit at that point but some may prefer those
be a binpkg.

I have no problem with it being optional.

-- 
William L. Thomson Jr.


pgpZrNRHTl9GN.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

On Wed, 9 Aug 2017 22:23:41 +0200
Francesco Riosa <viv...@gmail.com> wrote:

> 2017-08-09 17:33 GMT+02:00 William L. Thomson Jr. <wlt...@o-sinc.com>:
> 
> > On Wed, 9 Aug 2017 11:07:04 +1000
> > "Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:
> >
> > > > What then is the benefit? If what is installed is the same from
> > > > package manager or binpkg. Also your redistributing another's
> > > > package in binary format which may not be legally allowed.
> > >
> > > The difference is that how the package manager/ebuild installs the
> > > package may be better suited to the environment than what upstream
> > > expects (such as upstreams that install through a .run file)
> >
> > I fail to see how basically skipping src_install and maybe some
> > prepare stuff that makes it better suited to an environment.
> > Can you explain that further?
> >
> > These packages are just exploded tarballs. I fail to see the benefit
> > to repacking those into another tarball to be exploded. At best
> > skipping src_install and/or prepare, seems to be the only
> > difference.
> >
> one such benefit is that the binhost is known and managed by someone
> you trust, SRC_URI point to the wider and dangerous internet.

Interesting argument, saying upstreams cannot be trusted. Nor Gentoo
with its manifests and hashes of the files referenced in SRC_URI. Given
that most will come from Gentoo mirrors not upstream servers. Ignoring
that the binhost has to use these SRC_URI's just the same. It makes
sense in very strange way.

FYI binpkgs have no hash. If someone did something malicious within the
binhost to the binpkgs. You have no way of knowing. Yes the same can
happen with ebuilds and manifest. But easy to sync portage and see if a
manifest has changed.

Therefore relying on binhost as means of security is possible but odd,
as it leaves things open to potentially larger issues.

> So please leave this as a configurable choice.

For some things configurable would make sense. For things like fetch
restricted, it would not. Since it is not legal to mirror that stuff to
begin with. It surely is not to re-package.

-- 
William L. Thomson Jr.

pgp_OCWY10rTw.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

On Wed, 9 Aug 2017 11:07:04 +1000
"Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:

> > What then is the benefit? If what is installed is the same from
> > package manager or binpkg. Also your redistributing another's
> > package in binary format which may not be legally allowed.  
> 
> The difference is that how the package manager/ebuild installs the
> package may be better suited to the environment than what upstream
> expects (such as upstreams that install through a .run file)

I fail to see how basically skipping src_install and maybe some prepare
stuff that makes it better suited to an environment.
Can you explain that further?

These packages are just exploded tarballs. I fail to see the benefit
to repacking those into another tarball to be exploded. At best
skipping src_install and/or prepare, seems to be the only difference.

I see no difference in installing kernel sources via source ebuild or a
binpkg, pre-built ebuild binary. Other than the time it takes to
re-package the kernel sources into another tarball.

-- 
William L. Thomson Jr.

pgprjYBDQKsdt.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

On Wed, 9 Aug 2017 10:29:40 +1000
"Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:

> On 09/08/17 04:20, William L. Thomson Jr. wrote:
> > On Tue, 8 Aug 2017 19:32:48 +0200
> > Kristian Fiskerstrand <k...@gentoo.org> wrote:  
> >>  - You might be applying local patches through /etc/portage/patches
> >> that are distributed to all clients  
> > 
> > This might be the strongest reason. Though would only apply to stuff
> > like say kernel sources. Not sure what patches could be applied to a
> > binary ebuild, -bin. A patch would not effect src_install per my
> > understanding.  
> 
> There's also the fact that binpkgs may be manually installed exactly
> as the package manager would have installed it, rather than extracting
> whatever upstream supplies verbatim. 

What then is the benefit? If what is installed is the same from
package manager or binpkg. Also your redistributing another's package
in binary format which may not be legally allowed.

> This includes things like any wrappers, desktop files or symlinks
> created by the ebuild, or other such downstream-isms.

If it was made via package manager. If it was made via quickpkg, it
maybe different than if made by package manager.

-- 
William L. Thomson Jr.


pgpM0WgebH6wT.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

> > On 08/08/2017 07:23 PM, William L. Thomson Jr. wrote:  
> > >> it can already be controlled through env files.
> > > I was thinking it might, but having used them to skip other
> > > hooks. I was thinking they could not be used as such for binary
> > > packages. Have you confirmed such is possible?  Could you provide
> > > a link or example? Thanks!
> > 
> > try something like:
> > /etc/portage/env/nobin:
> > FEATURES="-buildpkg"
> > 
> > /etc/portage/package.env/nobin:
> > sys-kernel/gentoo-sources nobin  
> 
> That may work, I was not thinking to negate.  Trying it out now. But
> may lead me to another need... :)

My other need is that it does not seem you can use env files or patches
in profiles. I think I can do the env stuff via other means. Like
package.use. I do not want it in make.defaults, as this is per package.

The problem with env files is managing them per system. I want to do
things like that in profiles. It is to much work to manage that stuff
on each system. Even using things like ansible. Which is why I have
moved to custom profiles rather than per system stuff.

I will need to experiment a bit more. But IMHO a variable that can be
set in an ebuild, and bypassed if needed by operator at emerge time is
the simplest approach.

-- 
William L. Thomson Jr.

pgp_WKOlHcPmv.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

On Tue, 8 Aug 2017 20:15:07 +0200
Kristian Fiskerstrand <k...@gentoo.org> wrote:

> On 08/08/2017 08:10 PM, William L. Thomson Jr. wrote:
> >> I'm not sure explicitly about environment files, but it's an
> >> option to emerge.  For instance, I've added this to my
> >> EMERGE_DEFAULT_OPTS to ensure none of the following are built:
> >>
> >> --buildpkg-exclude "virtual/* sys-kernel/*-sources dev-perl/*
> >> perl-core/*"  
> > Something like this would NOT be desirable. It would have to be
> > done on every system.   
> It would have to be set on every binhost, not every client system..
> that said, I prefer env approach as it is easier to track changes
> properly in a CVS

That is assuming clients do not have FEATURES="buildpkg". I have that
set just in case I merge some package directly on a system. I have the
binary ready for others. I am trying out the env route now, but may
need some changes there.

Most are made on the binhost, but not all. Also I am not necessarily
using a binhost per se. I have portage on shared NFS. I also rsync some
binaries between NFS servers.

-- 
William L. Thomson Jr.

pgpzyH21mFLVx.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

On Tue, 8 Aug 2017 19:32:48 +0200
Kristian Fiskerstrand <k...@gentoo.org> wrote:

> On 08/08/2017 07:23 PM, William L. Thomson Jr. wrote:
> > Can you think of any? I cannot see any operator wanting a binary of
> > a binary, or a package of sources. When they already have a
> > sources  
> 
>  - The machine you're installing it on might not have internet access
> so you want to have the files stored in a single location for
> wrapping it up.

Not sure that would be any different between distfiles and packages.

>  - You might want an audit trail of installed packages, so using the
> binary files on specific media ensures same copy is installed
> everywhere

Doesn't the manifest/hash aspect of ebuilds ensure that for the
tarballs already? If installing same version, same tarball, Its all the
same already.

>  - You might be applying local patches through /etc/portage/patches
> that are distributed to all clients

This might be the strongest reason. Though would only apply to stuff
like say kernel sources. Not sure what patches could be applied to a
binary ebuild, -bin. A patch would not effect src_install per my
understanding.

> On 08/08/2017 07:23 PM, William L. Thomson Jr. wrote:
> >> it can already be controlled through env files.  
> > I was thinking it might, but having used them to skip other hooks. I
> > was thinking they could not be used as such for binary packages.
> > Have you confirmed such is possible?  Could you provide a link or
> > example? Thanks!  
> 
> try something like:
> /etc/portage/env/nobin:
> FEATURES="-buildpkg"
> 
> /etc/portage/package.env/nobin:
> sys-kernel/gentoo-sources nobin

That may work, I was not thinking to negate.  Trying it out now. But
may lead me to another need... :)

-- 
William L. Thomson Jr.


pgp09Sx3bV7Cd.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

On Tue, 8 Aug 2017 13:34:00 -0400
Ian Stakenvicius <a...@gentoo.org> wrote:

> I'm not sure explicitly about environment files, but it's an option to
> emerge.  For instance, I've added this to my EMERGE_DEFAULT_OPTS to
> ensure none of the following are built:
> 
> --buildpkg-exclude "virtual/* sys-kernel/*-sources dev-perl/*
> perl-core/*"

Something like this would NOT be desirable. It would have to be done on
every system. Package env files, if possible, would be a better
approach as that could be distribute to be consistent on all systems.

-- 
William L. Thomson Jr.

pgpgDp0MP9oVI.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

On Tue, 8 Aug 2017 10:18:36 -0700
Rich Freeman <ri...@gentoo.org> wrote:
>
> Whether it belongs in the ebuild, or in metadata, is another matter.

The how, implementation, etc is not as important to me. I just think
there should be some means to prevent such. If there is not currently.

As mentioned there could be other uses/benefits of such depending on
how it is implemented. That is up to others. I just would like to not
have binaries made of packages I feel are a waste to be re-packaged
into a binpkg.

-- 
William L. Thomson Jr.

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

On Tue, 8 Aug 2017 19:11:18 +0200
Kristian Fiskerstrand <k...@gentoo.org> wrote:

> On 08/08/2017 06:37 PM, William L. Thomson Jr. wrote:
> > I make a lot of binaries for use on other systems, to expedite
> > updates. It does not make sense for some packages to ever be a
> > binary package.  
> 
> Any particular reason this decision shouldn't be left to the operator
> of the binhost rather than the package maintainer?

Can you think of any? I cannot see any operator wanting a binary of a
binary, or a package of sources. When they already have a sources
tarball. Maybe in the case of shipping binaries without sources. But I
am not sure if an binary ebuild ignores SRC_URI entirely.

I think moving binaries without needing the distfiles would be the
only reason why an operator may prefer binaries of stuff that does not
get compiled, just installed.

> it can already be controlled through env files.

I was thinking it might, but having used them to skip other hooks. I
was thinking they could not be used as such for binary packages. Have
you confirmed such is possible?  Could you provide a link or example?
Thanks!

-- 
William L. Thomson Jr.

pgpmdoJlHwS7Z.pgp
Description: OpenPGP digital signature

[gentoo-dev] Prevent binary/non-compiled packages from binary package creation

I make a lot of binaries for use on other systems, to expedite updates.
It does not make sense for some packages to ever be a binary package.

Packages like -bin packages or gentoo-sources, which are just sources.
Having binary ebuilds of those is of no benefit. I can be the opposite
causing things to be much slower. Like in the case of large things
packages like android-studio.

Just seems odd to make a binary of a binary, or repackage
gentoo-sources into a gentoo ebuild binary/binpkg. There is not really
any benefit either way for such packages.

It would be beneficial if ebuilds could have some internal variable
that prevents it from being a binary package. It should not prevent
merge or fail. Just never create a binary of this package, always use
the ebuild as normal. Even if someone is force installing using binary
flag or otherwise.

As most things I think this would require support in PMS, or next EAPI
at minimum. But I think the EAPI comes from PMS, so they are related.

-- 
William L. Thomson Jr.


pgptpvQm0C7kK.pgp
Description: OpenPGP digital signature

[gentoo-dev] Changing PMS to Portage Manager Specification

2017-08-01 Thread William L. Thomson Jr.

I think Gentoo council, developers, and portage developers should
consider changing the PMS, to something like Portage Manager
Specification, or Gentoo Portage Specification. Make it Gentoo
and portage specific, and others adhere to that standard.

I understand the rationale behind PMS. However there is really only 1
main package manager for Gentoo, portage. I am aware of pkgcore,
though thought more of it was in C. I think pkgcore is still behind
EAPI wise, so not at 6 yet. There is paludis, but it requires pretty
heavy changes and does not seem to run along side of portage as it once
did long ago. Not sure if anyone even has a system that has no portage
installed. No emerge command etc.

It seems a few times I have heard portage developers make comments
about being limited by PMS.  That seems odd. To me the PMS should be
limited by portage, not the other way around. PMS should be based on
portage. Then other package managers must change to comply with that
specification. Rather than how things are now.

I have no control or participate in either portage or PMS development.
It is just an observation from having some needs. Which seems could
happen with portage. But can only happen if in the PMS. Which itself is
a process. Not sure in that case the PMS helps to expedite Gentoo
development, and may hinder. Since portage can only do what PMS allows
it to do. I think that should be reversed.

This is not saying drop PMS, have no PMS, etc. Just reverse, free
portage developers to do what they feel is needed for Gentoo. Then
other package managers can adhere to that specification. Make it
entirely internal and specific to Gentoo.

The PMS seems pretty abstract and not specific to Gentoo. Why even
bother with that? Why not Gentoo set its own standards for package
management? It seems aspects of portage are used for things like
Chrome OS and CoreOS, as well as parts of Gentoo. But seems more usage
of portage and not other package managers. Why not make it the
flagship? Portage be the standard, the specification/reference
implementation and others comply.

IMHO PMS should not hold back portage development, but portage
development hold back the PMS. PMS based on portage, not vice versa.

This will be my only post. Feel free to insult me, etc as you like.
Just an idea for others to discuss.

-- 
William L. Thomson Jr.


pgp6yzvpOm0cW.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

2017-07-31 Thread William L. Thomson Jr.

On Mon, 31 Jul 2017 12:56:18 +1000
Sam Jorna <wra...@gentoo.org> wrote:
> 
> Sorry, I thought this thread was about whether to keep or discontinue
> the separation between stable and testing branches.

Yes and it was others that said lack of stable would effect
enterprise/professional usage. I simply said that argument was moot as
there are other objections beyond not having stable.

Most I know would say Gentoo as a whole is not stable, regardless of
any stable packages, branch, etc. They do not consider Gentoo stable.

FYI, I have always run Gentoo for professional usage. I have a
business. My business has always run Gentoo on all servers, desktops,
workstations etc. Those locally who have worked for me and in my LUG
know this fact. I have also interviewed with many companies in the US
who either did run Gentoo or still do. Thus I have some directly
knowledge on that shrinking market.

Beyond my opinion, gentoo -debian - suse -redhat
https://www.indeed.com/jobs?q=gentoo+-debian+-suse+-redhat=

Very few if any are after Gentoo skills. Change that to any other
distro and see the difference. Of course Gentoo is always mentioned
with others, but are they running Gentoo is the question. Seeking
Gentoo skills and companies running Gentoo are not the same.

gentoo
https://www.indeed.com/jobs?q=gentoo+=

It is always lumped in with others, rarely by itself.

-- 
William L. Thomson Jr.

pgpHPsz2_7Qux.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

2017-07-31 Thread William L. Thomson Jr.

On Mon, 31 Jul 2017 14:59:25 +0200
"Andreas K. Huettel" <dilfri...@gentoo.org> wrote:

> Am Montag, 31. Juli 2017, 04:44:58 CEST schrieb William L. Thomson
> Jr.:
> > 
> > How about no foundation. Not even a legal entity. No certifications
> > from vendors, nor for employees. No one to hire for official
> > support. There are so many things far beyond anything having to do
> > with a stable tree or not.  
> 
> I was *this* close to nominaing you for Trustee, until I realized
> you're not even a foundation member...

Wait what? You blocked me from returning as a developer. Based on my
human relation skills, or in your opinion lack there of
https://bugs.gentoo.org/show_bug.cgi?id=135927#c43

How would you think I be fit for foundation Trustee? Which is a liason
type role, at least with outside entities. That makes  little to no
sense. A developer need technical skills more than personal. A Trustee
needs personal and not so much technical Great logic!

It seems that foundation membership been messed up pretty bad. This
seems to be the list of members. Which seems to only be developers.
https://wiki.gentoo.org/wiki/Foundation:Member_List

Per the by laws, one is only removed from membership via voluntary
request, and/or majority vote of the trustees to remove a member.
https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.4._Continuation_of_Membership
https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.8._Voluntary_Withdrawal_from_Membership
https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.9._Termination_from_Membership

I may have requested removal, I seem to recall such. Though I am not
sure others have. Seems the foundation is missing many members. Unless
the trustees voted to remove many others.

Also developers are not automatically added per bylaws. They must
apply for such.
https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.3._Admission_of_Members

-- 
William L. Thomson Jr.

pgpEXLpdyOfib.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

2017-07-30 Thread William L. Thomson Jr.

On Mon, 31 Jul 2017 10:28:31 +1000
Sam Jorna <wra...@gentoo.org> wrote:
>
> Wouldn't it make more sense to make Gentoo *more* attractive to run in
> corporate environments, rather than simply saying "We're not RHEL so
> why bother"?

No disagreement. That has always been my interest. Though has not been
others. It was in part why I became a trustee. For things like vendor
certified hardware, looking into certifications,  events, and a whole
lot more. But people rather lambast, insult, and stand in the way rather
than either get out of the way or work with me.

It surely could happen without me but has not. I am definitely not
against such happening. But it would require tremendous change and
leadership. Which I do not see ever changing. I wish things were
otherwise.

> People do use Gentoo in production environments, both personally and
> professionally, even if it is those that have more investment in doing
> so than the average IT Joe. By removing stable, we would be reducing
> the potential arguments for the few who do want to use Gentoo in that
> sort of environment. We would be becoming more of a niche distro.

Preaching to the choir. That is not why companies I know who ran Gentoo
are leaving or left. One told me they did not want to be in the
operating system business. Stable or not, there are fewer companies
running Gentoo that were before. Due to other reasons that are not
changing, culture, etc.

Companies that run it today I doubt would change if stable went away.
If they left Gentoo, they have many reasons far beyond lack of a stable
branch/tree.

> "Hey, lets try Gentoo - it's really configurable."
> "What's their stable policy? How often does it break?"
> "Stable? What's that?"

How about no foundation. Not even a legal entity. No certifications
from vendors, nor for employees. No one to hire for official support.
There are so many things far beyond anything having to do with a stable
tree or not.

-- 
William L. Thomson Jr.

pgpvVleoxydNp.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

On Fri, 28 Jul 2017 21:45:57 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:

> William L. Thomson Jr. posted on Fri, 28 Jul 2017 16:10:42 -0400 as
> excerpted:
> 
> > It seems odd that upstream will release a package. Just for
> > downstream to consider it not stable. Did it get messed up during
> > packaging? Did it get messed up by the distro? The whole lag thing
> > does not make sense for Gentoo. Sooner released and tested on
> > Gentoo. Sooner bugs can be founded, reported back to upstream, etc.
> > Speeds up development. That is Gentoo's role in FOSS IMHO.  
> 
> Not so odd.  Gentoo's arch-stable has a different meaning than
> upstream's stable.  As a long time gentooer I'm surprised you weren't
> aware of this already.

If upstream does a new release, fixes bugs. Gentoo marks a previous
release stable. It is stabilizing a package with issues fixed upstream.
That does not make sense. Gentoo issues maybe good, but not upstreams.

I maintained packages like iText which used to have a 30 day release
cycle. Up till recently Jetty was about the same. As a end user, I
needed the bug fixes. Not the delay for it be marked stable.

I stopped running Redhat long ago due to time to vet updates. I run
Gentoo for the speed of being able to package and test out new code.

-- 
William L. Thomson Jr.

pgpjA1gvTVSJQ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

On Fri, 28 Jul 2017 16:12:26 -0500
"A. Wilcox" <awil...@adelielinux.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 28/07/17 15:10, William L. Thomson Jr. wrote:
> > Gentoo is as stable as YOU make it  
> 
> And by "YOU", that would be the people writing ebuilds and committing
> them without test suites or integration testing of any kind.  

I am not one of those. I am an outsider. A user, outside ebuilder :)

Having packaged hundreds of Java packages. I do not bother with the
tests. They can take just as long if not longer to get running than the
package itself. I find best testing is real world usage.

>The devs
> who yell and complain all day about "standards" and "not breaking the
> tree" then go and break the tree and violate any standard ever set.

In most any project, breaking the tree/master is frowned on, but
happens. Long as its speedily fixed, all is well.

> This attitude of "the user is to blame" is the reason I moved Adélie's
> upstream elsewhere.  

I did not mean to imply the user was to blame per se. If you buy a car,
do not maintain it, and it falls apart. Is it the manufacturers fault?

Gentoo is not your average "car" or distro. It requires considerable
more work. The result can be better and save considerable time. Yes I
know I just contradicted myself. 

When I was racing, they said
"A fast lap around the track is a slow lap in the cockpit".

The time saving in Gentoo in part is the rolling aspect, and gained
over long periods of time. Upfront you spend considerable time.
The more time spent, the smoother and faster things go.

In part why I tell many not to run it.  They are not going to put in
the time upfront to ensure it works for them in the long run. If the
are not going to put in the time. They likely should not own high end
car, that require abnormal maintenance in ways.

> I am still running Gentoo on a few production
> servers, but this whole thread and /especially/ this message has made
> me realise I'm probably better off with Fedora until Adélie is ready.

For many other distros maybe better suited. There are quite many.
FYI Enlightenment.org runs everything on Gentoo. They have had
discussions of moving away etc. I stay out of it.

What works for one is not the best for other. Gentoo is not the best
distro for everyone. It is really up to each to decide. Gentoo to me is
a Development distro. Which should not be seen the same as many others.

-- 
William L. Thomson Jr.

pgpz0HU8poHZG.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

Gentoo is as stable as YOU make it

I have run Gentoo exclusively as well for 14+ years, since ~2003. While
my production servers are all mostly stable, none are 100%. All
production systems have some ~arch packages, usually mine. Development
network and desktops/laptops have always been ~arch. I rarely if ever
have issues. I have long felt and state stability on such a
distro/platform is a misnomer.

If your system is unstable, it could be due to the lack of time you
spent making it stable. With some exceptions. Many time stable is more
unstable and has issues, sometimes fixed in ~arch. ~arch can be more
stable than stable.

That being said having been bit recently by a udev update that wanted a
file from /usr/lib, which I have on lvm, so it broke udev and booting
on ~arch. I reverted back, I did not file a bug.

Maybe the core profile/base system is maintained as stable and not, and
all the rest, packages are not stable or unstable, They are masked or
not. Things like tool chain, and base system should be stable. Beyond
that up to a package maintainer to mask or not. Masking new stuff is
underused.

It seems odd that upstream will release a package. Just for downstream
to consider it not stable. Did it get messed up during packaging? Did
it get messed up by the distro? The whole lag thing does not make sense
for Gentoo. Sooner released and tested on Gentoo. Sooner bugs can be
founded, reported back to upstream, etc. Speeds up development. That is
Gentoo's role in FOSS IMHO.

There are other distros if you want rock solid stability all the
way through with minimal effort. Though ever system admin I know has
changed their personal distro a few times due to one issue or another.
Even ones who work for vendors who sell Linux, and they carry 2 laptops.
While I remain on Gentoo, but telling them to avoid Gentoo. Many ran it
before and did not put in the effort. Not why I tell them to avoid.

Gentoo should get back to having the latest of all packages, and
testing integration. It is more a development distro, than mission
critical deployment. That possible and it can be rock solid for
mission critical uses. If the administrators make it such.

Gentoo is as stable as YOU make it

-- 
William L. Thomson Jr.


pgpi2cn00a1i5.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

On Fri, 28 Jul 2017 23:10:35 +1000
"Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:

> On 28 July 2017 8:44:20 PM AEST, "Andreas K. Huettel"
> <dilfri...@gentoo.org> wrote:
>
> >That's not feasible. It would kill off any semi-professional or
> >professional 
> >Gentoo use, where a minimum of stability is required. 
> >
> >(Try keeping ~10 machines on stable running without automation.
> >That's already 
> >quite some work. Now try the same with ~arch. Now imagine you're
> >talking about 
> >100 or 1000 machines.)  
> 
> And further, try proposing that to management - that you'll be
> managing hosts on a platform that has no "stable" to speak of.

The professional/management argument is silly. Most avoid Gentoo.
Most companies, want to be able to pay for support. Not to mention
certifications and such for those they hire. None of which Gentoo has
regardless of stability. Not to mention reputation...

Those that tend to run Gentoo have their own interest in such.  I have
seen many migrate from rather than to Gentoo. Large companies, who's
names we would all know. One of the few left is Meetup.com. They run
Gentoo as do some others. Seems Tivo does stuff with Gentoo, Google,
Sony, etc. Some tend to hire Gentoo devs...

-- 
William L. Thomson Jr.

pgp8mvKMErOs_.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

On Wed, 12 Jul 2017 17:23:43 +0100
"M. J. Everitt" <m.j.ever...@iee.org> wrote:

> On 12/07/17 17:07, Gordon Pettey wrote:
> > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
> > <wlt...@o-sinc.com <mailto:wlt...@o-sinc.com>> wrote:

> > That is my point. That message is always there. The chance that
> > it is ignored is very high.
> >
> >
> > Stop signs on the road are also always there. If you get arrested
> > for ignoring it, it is not because the stop signs are always there,
> > it is because you ignored it. Don't ignore the warning.  
> Can't help but think of "special snowflake" here 

More like saying something to me because it is me, despite that I
literally pointed that out to others. In a situation that actually
matters. This should be said to others not me. But everyone feels ilke
they need to comment something to me, that applies to another, but not
said to that other.

Again
https://archives.gentoo.org/gentoo-dev/message/a0470e1cc2c05afc1e30c09f3f239b24

Really funny stuff

--
-- 
William L. Thomson Jr.


pgpdqJA9f1X5O.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

On Wed, 12 Jul 2017 11:07:00 -0500
Gordon Pettey <petteyg...@gmail.com> wrote:

> On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
> <wlt...@o-sinc.com> wrote:
>
> > That is my point. That message is always there. The chance that it
> > is ignored is very high.
> >
> >
> Stop signs on the road are also always there. If you get arrested for
> ignoring it, it is not because the stop signs are always there, it is
> because you ignored it. Don't ignore the warning.

And again another commenting who did not follow the thread. Talking to
the wrong person, replying at the wrong point.

Who is ignoring warnings? Me or others?
https://archives.gentoo.org/gentoo-dev/message/a0470e1cc2c05afc1e30c09f3f239b24

Guess you missed where I was pointing out important warnings others
were ignoring. Much more so than the generic output that is always
present with emerge -C/--unmerge.

Also in what country do you get arrested for running a stop sign?

-- 
William L. Thomson Jr.

pgpL9CyAAquYA.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

On Wed, 12 Jul 2017 16:40:11 +1000
"Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:

> If my concern in removing a package was whether it was a dependency,
> it would make more sense to use --depclean in the first place. If I'm
> using --unmerge, it's because I want the package unmerged regardless.

But you can't remember what you installed or ate for dinner. What if you
are removing something you need?

> > Didn't you just say something about meaningful output vs noise?
> > That is always outputted and ends up becoming what you are saying.
> > Funny!  
> >
> And your suggesting adding more noise to it... Funny, I know.

No a warning that mentions the package not being removed is not noise.
It is useful output, like the warnings that exist for other things now.

I guess in your opinion this warning is noise to you.

!!! 'sys-devel/gcc' is part of your system profile.
!!! Unmerging it may be damaging to your system.

It is YOUR comments that are funny, and going in a circular argument
just to be argumentative and bringing nothing useful to the discussion.
Which should be over now that bugs are filed

> > Depclean the user is cleaning things they are not aware of. Unmerge
> > the user is removing something directly. They may think they do not
> > need it.  
> 
> No.
> 
> '--depclean' is the user removing things they are not aware of.

You literally just re-typed what I did above replacing cleaning with
removing. Are you paying any attention?

> '--depclean foo' is the user removing something they /are/ aware of
> *if it's not a dependency*.

That does not work the same. It will not remove a package from world.

> '--unmerge foo' is the user explicitly removing something regardless
> of whether it's a dependency.

BUT they are warned now for things that are in a profile or set. Thus
they should be warned if a dependency. Its simply, but clearly your
having a hard time grasping.

> Therefore, '--depclean foo' can be seen as a safe '--unmerge foo'
> which, from what I understand, is what you're aiming for.

No, as they are not the same. You cannot remember what you ate. Please
stop trying to assume what I am after. Clearly we are very different. I
know what I ate last night...

> That's what the current warning to --unmerge says - removing packages
> can break things, so please make sure this isn't a dependency and you
> really want to remove this.

They do not say anything about dependencies. It says the same message
for everything. In some cases for system and set packages you get a
warning.

> How does replacing one warning with another warning that may or may
> not be meaningful ("maybe it's a dep, maybe it isn't" as opposed to
> "this can be dangerous, please make sure you know what you're doing")
> make it any better?

It is not replacing a warning. It is adding the same warning that exist
in other situations in one it does not exists now, removing
dependencies.

Clearly you are having a hard time grasping this very simple concept.
I am done, reply if you like, but this thread is serious noise now...

-- 
William L. Thomson Jr.

pgpI3YxGNphyg.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

On Wed, 12 Jul 2017 15:49:14 +1000
"Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:
>
> I have trouble remembering what I ate for dinner last night, let alone
> what I may or may not have merged a week, month or year ago, or what
> options I used when merging it.

And if you used --oneshot, it is also saying you are not maintaining
your system or ever running --depclean. Since anything you installed
via --oneshot would be removed with --depclean.

> > What harm does a warning do?  
> 
> Depends on the user, which can't really be avoided, but means that
> warnings should be clear and meaningful, otherwise they become
> background noise.

The example in the bug is as clear is it can get.

!!! 'sys-devel/gcc' is a dependency of another package on your system
or
!!! 'sys-devel/gcc' is a package not found in system profile or world
or
!!! 'sys-devel/gcc' may not have been installed by you
or
some other message

> Such as:
> 
> emerge --unmerge dev-python/keyring
>  * This action can remove important packages! In order to be safer,
> use
>  * `emerge -pv --depclean ` to check for reverse dependencies
> before
>  * removing packages.

Didn't you just say something about meaningful output vs noise? That is
always outputted and ends up becoming what you are saying. Funny!

> >> or may have been installed as an orphan but is now a
> >> dependency.   
> > 
> > Now being a dependency the warning would be valid.  
> 
> "Sometimes being accurate" is not the most noble of goals.

What?

> So the idea is to duplicate the functionality of '--depclean
> 

NO!!!

emerge --depclean gcc 

is not the same as 

emerge --umerge gcc

Depclean the user is cleaning things they are not aware of. Unmerge the
user is removing something directly. They may think they do not need it.

>' without actually checking to see if the package is a
> dependency,

Word it how ever. If the user did not install, they should be warned on
removal of a package they did not install.

> only whether it is listed in a set; or to check if it's a
> dependency of /something/ and, if so, redirect the user to the
> command they should be using anyway?

You mean like emerge --unmerge does already that you pointed out
above. After mentioning useful messages vs noise.  Again funny!

-- 
William L. Thomson Jr.

pgpQjPL9OBJa_.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

On Wed, 12 Jul 2017 15:19:32 +1000
"Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:

> On 12/07/17 15:14, William L. Thomson Jr. wrote:
> > Is it in system?
> > Is it in a set?
> > Is it in world?
> > If no to all, its a dep, warn!  
> 
> All this says is whether the package was explicitly installed and
> recorded in world, or is a member of @system. The target package may
> or may not be a dependency, may or may not have been --oneshot'd.

Then when the user sees the warning they can discard knowing they
merged the package with --oneshot.

What harm does a warning do?

> It may have been installed as a dependency but the requiring package
> was removed,

Then the person failed to run --depclean and maintain their system.
Either way, did the person install the package directly?

If the package was not installed by the user. Should they not be warned
about removing something they did not install?

> or may have been installed as an orphan but is now a
> dependency. 

Now being a dependency the warning would be valid.

>Assuming that if it's not in a set it must be a dependency  is
>incorrect and misleading.

Again there are various ways. There cannot be that much overhead to
check if a single package depends on one being removed. If you cannot
use simpler methods as mentioned.

Clearly people have objections to warnings about packages users did not
install themselves

-- 
William L. Thomson Jr.

pgp9MrrKBm3bB.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

On Wed, 12 Jul 2017 15:00:30 +1000
"Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:
> 
> My point was that --unmerge is not intended to be dependency-aware.
> --depclean is. As far as I can tell, that is the point others have
> been trying to make as well, when pointing out the differences
> between -c and -C.

Sure but that is easily addressed.

How does emerge know a package is in system profile or a set?
Similar methods or others can be used to determine if a user installed
a package.

In a clean scenario, with a world file that ONLY contains stuff the
user merged directly. Then emerge could simply check that file, against
the stuff it already checks now.

Is it in system?
Is it in a set?
Is it in world?
If no to all, its a dep, warn!

It is really NOT complex, nor does it require complex depgraph or any
of the function of --depclean/-c.

Thus I say once again, mentioning anything to do with depclean is not
relevant and side tracks the discussion. There is no need. If you did
want to actually see if any deps existed. All you need is to see if
there is 1 installed package that needs the one a user is trying to
install. No need for a complete depgrah etc.

There are several ways to go about this that are not complex.

-- 
William L. Thomson Jr.

pgp_HMN_6hxYC.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

On Wed, 12 Jul 2017 14:17:30 +1000
"Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:
>
> --depclean is doing exactly what it is supposed to. If called with no

Problem is I was talking about removing packages directly. It served no
purpose in this discussion.

Since I use --depclean, not -c. I was assuming -c was unmerge like -C,
but it is not. Others brought that up and sidetracked things. I just
did not catch and mistakenly went down that wormhole.

> 
> > It is not the same as -C, which is remove a package directly.
> > 
> >  --unmerge (-C)  
> 
> Correct, --unmerge will remove a package without considering
> dependencies (give or take a few special cases). It is usually (or, at
> least, should generally be) reserved for those taking a hammer to a
> problem or with a particular desire to recover a broken system.
> 
> Again, it's doing exactly what it's supposed to - removing a package
> you've told it to remove (unless it's one of the few
> almost-always-critical packages).

Yes and if you see bug. All I am saying is adding warnings when someone
goes to remove a dependency. Since a dependency IS a critical package :)

Add warning message when -C/--unmerge a dependency like system,
profile, and set files.
https://bugs.gentoo.org/show_bug.cgi?id=624630

-- 
William L. Thomson Jr.

pgp5mukQUK6hy.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

On Wed, 12 Jul 2017 04:43:41 +0100
"M. J. Everitt" <m.j.ever...@iee.org> wrote:
> 
> Of course, you can do what Poettering did, and write your own solution
> .. or fork portage to do things the way -you- want .. but don't
> reinvent the wheel for the rest of us .. that's what Choice and
> Gentoo is all about ...


Its not for me. It is not re-inventing the wheel. It is safe guard
stuff that benefits all. See bugs.

-- 
William L. Thomson Jr.


pgp9uZ61eHSJZ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

On Tue, 11 Jul 2017 23:22:12 -0400
"Walter Dnes" <waltd...@waltdnes.org> wrote:
> 
>   Step back for a minute, and relax.  There is a reason you're getting
> blowback.  You're asking for changes that would affect everybody else.
> This is similar in principle to what Lennart Poettering did, and
> you're getting the same reaction he got.  I understand that *YOU*
> want changes to how Portage works on *YOUR* machine.  No problem.  Set
> EMERGE_DEFAULT_OPTS in make.conf.  If you want excruciating detail on
> --depclean then check the small script I posted elsewhere in this
> thread.  Portage has many customization options; use them.

I am relaxed, and if you understand what I am proposing. It will only
help everyone. There is no harm in adding warmings that provide
additional information.

Preventing stuff from being added to world is moot, as that stuff comes
from something else, profile, set, etc. It being added to world serves
no purpose, Just can cause issues down the road. Stuff remaining that
may have not been wanted, but ended up in world so persists and gets
updated, etc.

What purpose does system profile packages saved in world serve?

These changes are NOT for me... I can edit and code myself. This is for
others per this discussion. Others brought up sets accidentally
removing system stuff, etc. Thus these ideas came up as ways to prevent
others from shooting themselves in the foot.

The blowback is mostly because its me, and people are misunderstanding
things. Like the mention of -c/--depclean. Which does not have the same
function as -C/--unmerge. That sidetracked things and added nothing.

>   If you can't be bothered to use available customization options to
> set up your machine to your liking, but ask for a change of defaults
> that also affects everybody else, don't be surprised at the negative
> reaction. You would've gotten a much better reception, if you had
> gone to the gentoo-user list and asked "How do I tweak Portage to do
> this, that, and the other".

How many times do I have to say I use -1, and others like -O.  People
do not pay attention...

Again I do much of this via ansible and profiles. I am not even using a
world file, or sets even. I did use sets before my custom profiles. Did
I always use -1 for the past over a decade no? Should all users have to
in order to prevent needless stuff from being recorded in world.

Please do not assume what I am or am not doing and problems I am not
having. This is stuff for others. I am seeing problems that OTHERS can
run into per the discussion on sets. From things OTHERS mentioned as
issues with using sets.

Bugs are filed.

-- 
William L. Thomson Jr.

pgp9XVKcFMdK4.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

On Sat, 8 Jul 2017 18:20:54 -0400
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:

> For anyone interested in such, I opened a feature request bug for
> allowing use of sets in profile packages. 
> 
> https://bugs.gentoo.org/show_bug.cgi?id=624300
> 

Subsequent bugs from the discussion

portage should not add system, world, profile, set, or dependent
packages to world, like -1/--oneshot
https://bugs.gentoo.org/show_bug.cgi?id=624628

Add warning message when -C/--unmerge a dependency like system,
profile, and set files.
https://bugs.gentoo.org/show_bug.cgi?id=624630

Thank you for all's input on this topic and related. This should
conclude the thread now, or at least my part. :)

-- 
William L. Thomson Jr.

pgp9kxXmMa3WO.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

On Tue, 11 Jul 2017 14:32:27 -0700
Daniel Campbell <z...@gentoo.org> wrote:
>
> I understand where you're coming from, I just thought to give a few
> tips to make life a bit easier for you since it works out pretty well
> for myself. I think your idea has merit, just unsure of where the
> functionality goes, since I'm not a Portage developer.

I have been using the -1 option myself for some time. I have also moved
away from having anything in world file. I have my own profiles and
such. Just not committed to my public overlay yet.

This is mostly for others. I do what ever I need directly for myself if
it really becomes an issue for me. But I appreciate the thought!

> I think the hard part of implementing this will be detecting whether a
> command-line-given package is (a) in a set/profile/world and (b) part
> of a dependency tree (i.e. shouldn't be removed).

I do not think it will be that complex. It already does this now for
system, world, and set files. It must be looking at files already.
Having it look at say /var/lib/world is just another file/location.

> -c already traverses the dependency tree. This one message may mean
> iterating through the list of candidate packages and comparing them
> against a set/profile/world *per package*, unless the vdb/cache makes
> this lookup cheap in terms of cycles. The message would be helpful,
> though again, eix-test-obsolete might be the right tool to build that
> feature into. I'd be interested in following the bug discussion, if
> you've already filed it.

The looking at say world file is more an issue for -C than -c. -c knows
there are deps. Thus all it needs is an additional minimal message. It
already says to see deps use -v. It just does not say, why it took no
action. But actually now that I looked at -c, it is completely wrong.

I should have caught that sooner. -c does not remove a package, it just
removes its deps.

-c == --depclean.

It is not the same as -C, which is remove a package directly.

 --unmerge (-C)

Not even sure why anyone suggested -c. That explains why I use -C and
not -c, but I do use --depclean. This whole thread and topic really got
sidetracked big time with -c vs -C.

-c should never be mentioned. I was about to file a bug when I noticed
such.

emerge -c gcc, would never remove gcc, only run depclean
emerge -C will remove gcc

> If you're really interested in the message from -C, it could be done
> by checking the argument list for packages in sets or profiles. But
> it's going to incur similar overhead that -c has because it
> necessarily has to check some sort of list before producing the
> message.

Yes this is just about -C, and as stated previously. Other stuff
already hits files, this is not different really.

> I do not think this message belongs in -C output, however; -C is
> intentionally meant for operations where you don't care what happens
> to the dependency tree

Not true, as I have shown, -C will warn on removing system, world, and
set packages.

-C will NOT worn on dependencies, which it should. Using the world file
and others to know if a package is a dep or in one of those files.

> Please don't interpret this e-mail as aggressive or dismissive. I'm
> simply trying to offer explanation and guidance to help you make this
> happen. It's clear that you care about it, so I'm sure there's a way
> for this to go forward.

I do not, long as it is not insulting which it does not contain
anything of the sort. Though the discussion or mention of -c/--depclean
is really off topic. That confused and side tracked things.

-- 
William L. Thomson Jr.

pgpusktgEpxqE.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

On Tue, 11 Jul 2017 13:27:57 -0700
Daniel Campbell <z...@gentoo.org> wrote:

> On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote:
> > On Mon, 10 Jul 2017 19:22:47 -0400
>
> > A rule for portage could be;
> > 
> >  - If the package is not in world and already installed. Do not add
> > the package to world. If you are re-emerging a package already
> >installed. You do not have to use the -1 option. 
> > 
> > I have polluted so many world files with system packages and/or
> > dependencies I re-emerged directly without -1. Those IMHO should
> > never have been recorded to that file. They were brought in by
> > other things. Only things in my world should be packages merged
> > directly, not from profile, set, or a dep.

> Portage's fault. If you don't want a package added to a set or world,
> you'll need to use the -1 (--oneshot) option.

Did you even read above? I clearly state WITHOUT -1 option

> I added it to my default
> emerge options in make.conf for exactly that reason (clean world);

The point is people should not have to do such. Or remember to always
use -1 when re-emerging a dep, system, world, or set package.

> though, I have to be careful and make sure packages I care about are
> in a set somewhere or --depclean will wipe'em out. In short, Portage
> won't stop you from shooting yourself in the foot.

If those package are in your world file portage will not remove on
depclean.

> If you decide you want to add a package to world without re-merging
> it, -n (--noreplace) will do the job.

Or you can add it to the world file, or your profile/packages
in /etc/portage, etc. There are other places, one does not have to
emerge every package then want in world. Just the same it should not
add stuff just the same from system, world,  sets, or deps of any of
those 3.

> That said, having helpful messages is a good addition, but needs to be
> done in a way that is unambiguous and gives the user a clear solution.

So now it must be clear to the user? That is the entire point I am
making. The output now is not clear... But in improving such now there
is concern over something no one cares about now Funny stuff!!!

-- 
William L. Thomson Jr.

pgpAbQgpYXXiY.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

On Tue, 11 Jul 2017 02:23:56 +0100
Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:

> On Mon, 10 Jul 2017 18:14:23 -0700
> Raymond Jennings <shent...@gmail.com> wrote:
> > If I may ask, does anyone have any profiling information one way or
> > the other to shed light on the situation?  

There are profilers for python. Python devs can comment on such. I am
not sure about other things like looking for leaks etc. I was not able
to run python stuff through valgrind. At least I could not run
java-config through valgrind like I do with jem.

IMHO python all around is just not as robust and should not be used for
such purposes. There maybe ways to make it faster. For something with
the complexity, it should really be done in something more robust. Just
requires talent to make it such.

> Paludis does complete dependency and unused package tracking for
> everything by default. Any performance difficulties are
> implementation-related, not a fundamental problem.

I agree its a portage issue. Not saying anyone's code sucks or
discounting their efforts. Things do not have to be slow.

I mentioned this directly to some portage people in person a few years
ago during a meeting in Southern California... Around the time I put
jem on Github.

It is really hard to start over if/when that happens. Thus doing it
piece meal maybe easier. Though may still end up with spaghetti in the
end. Hopefully it runs fast and taste good :)

-- 
William L. Thomson Jr.

pgpPx38rQhqRU.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

On Tue, 11 Jul 2017 02:09:12 +0100
Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:

> On Tue, 11 Jul 2017 00:24:10 +0200
> Michał Górny <mgo...@gentoo.org> wrote:
> > William, I'm not sure if you're aware of how package managers work
> > but checking reverse dependencies of a package takes significant
> > amount of time. Changing -C to do that would be a serious
> > performance regression. Which would result in users requesting yet
> > another option to disable this.  
> 
> Eh, that's a Portage performance problem, not a package manager
> performance problem.

I do recall years ago paludis being much faster, and providing more
detailed information on package slots, archs, etc. In a graph like
output if I recall. It was super useful in package maintenance. It
really helped with cleaning things safely!

Last I checked in out ~year or so, It was just to difficult to get to
work with portage. Paludis has changed considerably. Seems you need to
change a system to work with it. Not as use along side of portage as it
was in the past. It would be nice to be able to compare it side by side
to portage. Though I know it has some different features.

Need to check out pkgcore. Though I am not the one complaining about
time. Just saying for those who are...

-- 
William L. Thomson Jr.

pgp78rFL5QpTN.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

On Mon, 10 Jul 2017 20:12:28 -0500
R0b0t1 <r03...@gmail.com> wrote:

> On Mon, Jul 10, 2017 at 6:56 PM, William L. Thomson Jr.
> <wlt...@o-sinc.com> wrote:
>>
> > IMHO anyone complaining about time taking for dependency resolution
> > etc. They should spend THEIR time writing stuff in a real native
> > language for speed.
> >
> > The difference I see with jem[1] vs java-config, is ridiculous.

> > If aspects of portage were done in C or C++, or maybe even Go. There
> > would be substantial performance improvements. The existing python
> > code can remain. Python can load and call functions from C/C++ DSO.
> > And vice versa, calling Python code from C/C++. I would say C vs
> > C++ but that is up to others.
> >  
> 
> https://wiki.gentoo.org/wiki/Q_applets
> 
> What you're suggesting is actually really hard, and the root of the
> problems tend to be graph traversals and path searches (for
> dependencies) not so much miscellaneous milliseconds spent in
> interpreter overhead.

I am aware in a way. Depends on how implemented. This has to hit
package.env files. But what you see below comes from a dependency list.
I have packages with even more deps.

jem --help

 Package Options:
  -d, --with-dependenciesInclude package dependencies in
--classpath and --library calls
  -p, --classpath=PACKAGE(s) Print entries in the environment classpath
for these packages

jem -d -p eclipse-jdt-core-4.6
/usr/share/ant-core/lib/ant.jar:/usr/share/ant-core/lib/ant-bootstrap.jar:/usr/share/ant-core/lib/ant-launcher.jar:/usr/share/eclipse-core-contenttype-4.6/lib/eclipse-core-contenttype.jar:/usr/share/eclipse-core-filesystem-4.6/lib/eclipse-core-filesystem.jar:/usr/share/eclipse-core-jobs-4.6/lib/eclipse-core-jobs.jar:/usr/share/eclipse-core-resources-4.6/lib/eclipse-core-resources.jar:/usr/share/eclipse-core-runtime-4.6/lib/eclipse-core-runtime.jar:/usr/share/eclipse-equinox-app-4.6/lib/eclipse-equinox-app.jar:/usr/share/eclipse-equinox-common-4.6/lib/eclipse-equinox-common.jar:/usr/share/eclipse-equinox-preferences-4.6/lib/eclipse-equinox-preferences.jar:/usr/share/eclipse-equinox-registry-4.6/lib/eclipse-equinox-registry.jar:/usr/share/eclipse-osgi-4.6/lib/eclipse-osgi.jar:/usr/share/eclipse-text-4.6/lib/eclipse-text.jar:/usr/share/osgi-core-api-6/lib/osgi-core-api.jar:/usr/share/eclipse-core-expressions-4.6/lib/eclipse-core-expressions.jar:/usr/share/osgi-compendium-6/lib/osgi-compendium.jar:/usr/share/eclipse-osgi-services-4.6/lib/eclipse-osgi-services.jar:/usr/share/osgi-annotation/lib/osgi-annotation.jar:/usr/share/felix-resolver/lib/felix-resolver.jar:/usr/share/eclipse-core-commands-4.6/lib/eclipse-core-commands.jar:/usr/share/icu4j-59/lib/icu4j.jar:/usr/share/glassfish-persistence/lib/glassfish-persistence.jar:/usr/share/osgi-foundation/lib/org.osgi.foundation.jar:/usr/share/tomcat-servlet-api-4.0/lib/el-api.jar:/usr/share/tomcat-servlet-api-4.0/lib/jsp-api.jar:/usr/share/tomcat-servlet-api-4.0/lib/servlet-api.jar:/usr/share/eclipse-jdt-core-4.6/lib/eclipse-jdt-core.jar

jem
real0m0.004s
user0m0.000s
sys 0m0.005s

java-config
real0m0.075s
user0m0.057s
sys 0m0.017s

On further runs of java-config
real0m0.121s
user0m0.105s
sys 0m0.017s

jem never exceeds 0m0.005s for any real, user, or sys

> Then again, I suppose there will be people on computers slow enough
> where the latter does make a difference.

arm? Laptops? Even if not speed, resources. But when its used for many
packages called over and over. It can start to add up little by little.
We can all use more time.

-- 
William L. Thomson Jr.


pgp8KTatcPSBN.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

On Mon, 10 Jul 2017 17:47:45 -0500
Gordon Pettey <petteyg...@gmail.com> wrote:

> On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny <mgo...@gentoo.org>
> wrote:
> 
> > On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
> > > Stop getting lost in the weeds
> > > You all are making this about -c vs -C. I am not talking about
> > > that!
> > >
> > > LET ME CLARIFY
> > >
> > > When using -C, portage SHOULD warn for dependencies like it does
> > > for profile and set packages, PERIOD. NOTHING to do with -c vs -C.
> > >
> > > When using -c the output should say in layman's terms,
> > > "Not removing package A because it is a dependency"
> >
> > William, I'm not sure if you're aware of how package managers work
> > but checking reverse dependencies of a package takes significant
> > amount of time.
> 
> 
> for x in $(eix -I --only-names); do time equery g $x > /dev/null; done
> 
> The only single package on my system that took more than 2 seconds
> total time was gcc. The idea that that is too much time to add to
> emerge -c or -C, which in my experience already takes multiple
> seconds to run anyway is kind of silly.

IMHO anyone complaining about time taking for dependency resolution
etc. They should spend THEIR time writing stuff in a real native
language for speed.

The difference I see with jem[1] vs java-config, is ridiculous.
Sometimes I merge hundreds of java packages. All those milliseconds add
up. Not to mention resources, ram, CPU, and all drains your battery...

If aspects of portage were done in C or C++, or maybe even Go. There
would be substantial performance improvements. The existing python code
can remain. Python can load and call functions from C/C++ DSO. And vice
versa, calling Python code from C/C++. I would say C vs C++ but that is
up to others.

Put my time where my mouth is... Well I did, its called jem. What is
jem? Its java-config ported to C. I would be looking to port more of
Gentoo's tools to C for longevity and speed. Not speed of development,
but speed for everyone else. Instead I am doing C for other projects.

1. https://github.com/Obsidian-StudiosInc/jem

P.S.
jem does need a bit more work to replace java-config entirely. Its
designed to not be Gentoo specific. There is little interest from
Gentoo, much less outside. Thus its more a case study than anything
benefiting anyone including myself. I will further it as I have
interest and time permits. Still have a few more defects to address.

-- 
William L. Thomson Jr.

pgpm9WoCEPEM4.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

On Mon, 10 Jul 2017 19:22:47 -0400
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
>
> That part does not require it to resolve deps. Just check world file,
> assuming its correct. Though could be thrown off if say gcc, or
> another was in the world file. I think the profile or set would catch
> that as it does now and generate a warning, regardless.

Speaking of gcc in the world file. I think portage should STOP adding
packages that are in the profile or a dep to world. If you merge a
package as part of a set, I am pretty sure it does not get recorded to
world, need to confirm, could be wrong.

A rule for portage could be;

 - If the package is not in world and already installed. Do not add the
   package to world. If you are re-emerging a package already
   installed. You do not have to use the -1 option. 

I have polluted so many world files with system packages and/or
dependencies I re-emerged directly without -1. Those IMHO should never
have been recorded to that file. They were brought in by other things.
Only things in my world should be packages merged directly, not from
profile, set, or a dep.

I will file a bug on that as well.

-- 
William L. Thomson Jr.

pgppvJ2qYUHfP.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds