Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists
On Mon, 4 Dec 2017 22:39:04 +0100 Kristian Fiskerstrand wrote: > On 12/04/2017 10:36 PM, William L. Thomson Jr. wrote: > > Sorry last one, directed to Alec, but all should read. > > I hope you really mean that, we've all heard you complaining about > this too many times already. The day everyone wanted has come, after this message. I will unsubscribe not to return. You all won in 2008, and again in 2017. Though this time I will not be back. I tried more than most anyone else would for a very long time. Gentoo wins I lose, I am fine with that. Please do not contact me off list in IRC or at all. I am done with the Gentoo community! Thank you and have a nice day! -- William L. Thomson Jr. pgp24Zi7cM0nL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
On Wed, 06 Dec 2017 09:51:23 +0100 "Andreas K. Huettel" wrote: > Am Mittwoch, 6. Dezember 2017, 00:40:11 CET schrieb William L. > Thomson Jr.: [...] > [...] > [...] > > Well, it's like listening to a broken record, which keeps repeating > the same snippet. At some point you stop listening, and at some point > you realize you should maybe remove it from the player. > Maybe you should go take more of my Firebird changes and put them in tree. Since you took over that package I mtainained and then merged in my changes from Linux UnderGround overlay that came from mine... Who do you think made the Firebird 3.x ebuild? I DID https://github.com/Obsidian-StudiosInc/os-xtoo/commits/master/dev-db/firebird See linux underground reporting issues with mine before adding it to their repository https://github.com/Obsidian-StudiosInc/os-xtoo/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+firebird See the date after they got it from mine :) https://github.com/linuxunderground/gentoo.overlay/blob/master/dev-db/firebird/firebird-3.0.2.32703.0.ebuild Then Andreas adding it to tree... HILARIOUS https://github.com/gentoo/gentoo/commit/e246873f43db77850c172263be72bc5153b23adb#diff-7dc5e9ed8a228dd8f564e17d66c5559e Also seems it took a few tries why? Not familiar with package? https://github.com/gentoo/gentoo/commits/master/dev-db/firebird Same package, mgorny 51 comment QA leading to more issues because he does not use, have a clue about it, or bothered to actually test... Due to his approach and stance I assumed his changes were correct. HUGE mistake on my behalf. Why in part mgorny does not like me All for a 1 line change to fix syslog-ng log file... https://bugs.gentoo.org/547442 mgorny going crazy on QA for a 1 line change Ridiculous! https://github.com/gentoo/gentoo/pull/101 Introducing new bugs that did not exist. GO QA https://github.com/gentoo/gentoo/commit/e246873f43db77850c172263be72bc5153b23adb#diff-7dc5e9ed8a228dd8f564e17d66c5559e And work since on things mgorny missed... https://github.com/gentoo/gentoo/commits/master/dev-db/firebird This generation is NO replacement for the previous They seem completely incapable of doing some things... There is more QA issues but that is just Firebird. Why is this PR still open? Or Java 9 PRs? Anyone working on that? Or just people like you complaining about those actually doing the work your not... or maybe cannot... https://github.com/gentoo/gentoo/pull/1358 https://github.com/gentoo/gentoo/pull/1721 https://github.com/gentoo/gentoo/pull/6033 Andreas you are a funny guy... -- William L. Thomson Jr. pgpgPxbjlzmHL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
On Wed, 6 Dec 2017 00:25:46 +0100 Kristian Fiskerstrand 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." 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 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 wrote: > On Tue, Dec 5, 2017 at 5:19 PM, Kristian Fiskerstrand > 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." wrote: > On Mon, 4 Dec 2017 14:43:15 -0800 > Matt Turner 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 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 wrote: > On Mon, Dec 4, 2017 at 10:52 AM, William L. Thomson Jr. > 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." 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 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 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 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 14:17:00 -0500 Alec Warner wrote: > > Clearly if Gentoo could be successful if millions of people were > killed; we would not choose to kill millions of people. > Clearly if Gentoo could be successful if dozens of people were > harassed; we would not choose to harass dozens of people? > > I think the advocacy is that people want a community where Gentoo can > be successful without needing to harass anyone. A noble goal eh? > If the cost of a successful Gentoo is people being harassed because it > cannot sustain a safe community; perhaps Gentoo shouldn't exist The fact that you were the one who caused the problems for me in 08. Who reported me to DevRel in 08 Alec? Are you proud of that some many years later? Did that help the Foundation or Gentoo? I was gone from 08-15 yet things did not improve and you are still here. That you ended up as a Trustee is ironic. Drive me out take my place and do nothing. Which Gentoo never did get any official status with IRS. No filings beyond the ones Daniel Robbins paid for out of his own pocket When he created the Foundation and donated Gentoo to the foundation. Least the work I did for the Foundation is visible and stands to this very day. Same bank account I helped establish after calling banks for 2 months solid post 911. Asking things like we have an international foundation with trustees not in the US. Does not ring any bells for money laundering or terrorism Perhaps people like you should not cause problems for and drive people like me away. Then maybe Gentoo would have a real legal foundation, budgets, weekly news letter paying for development, reimbursing developers for travel, conferences, etc. Pretty much everything FreeBSD has going on. You can see me referencing them any times in the -nfp logs from when I was a Trustee. Not to mention the lack of technical contributions. I can't find you Alec where are your commits? Or other activity? wlt@ws /usr/portage $ git shortlog -s -n --all | grep -i Thomson 55 William L. Thomson Jr wlt@ws /usr/portage $ git shortlog -s -n --all | grep -i Alec wlt@ws /usr/portage $ git shortlog -s -n --all | grep -i Warner Keeping all this out of tree https://github.com/Obsidian-StudiosInc/os-xtoo Much less other work on the Foundation. This is clear the people responsible for killing and harming Gentoo. Many like you remain from 2008. Still being just as destructive, masquerading as constructive. While doing what? Technical or Foundation wise? Show me the money :) -- William L. Thomson Jr. pgplnoN1SXetc.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 wrote: > On 12/04/2017 01:51 PM, William L. Thomson Jr. wrote: > > On Mon, 4 Dec 2017 13:15:32 + > > "M. J. Everitt" 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 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" 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....
ges. But I 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?
On Sat, 2 Dec 2017 16:13:47 -0500 Michael Orlitzky wrote: > > I'm not sure if anything is using that particular profile. I tried to > create a new subprofile myself, > > https://archives.gentoo.org/gentoo-hardened/message/ab7ef753aa88f21c8a05d667cf511a24 > > and wound up (indirectly) using arch/amd64/no-multilib as the parent > instead of your [1]. I think USE="pic" by default is the only > difference. > > In any case, until it becomes official, I'm probably just going to > fake the profile with a symlink to the no-multilib profile's > use.mask. That at least prevents me from building a multilib gcc, > glibc, and sandbox. Having created some profiles myself for my own purposes. Seems Gentoo could really use and benefit from Funtoo's Flavors and Mix-ins. Seems a much better approach than the current profiles situation in Gentoo. https://www.funtoo.org/Funtoo_Profiles "This new system is really a completion of the original cascading profile design that was co-designed by Daniel Robbins and Seemant Kulleen and implemented by Seemant Kulleen as part of Portage." https://www.funtoo.org/Funtoo_Profiles#History_and_Origins -- William L. Thomson Jr. pgp2HpSy9rLr7.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: cmake + ninja vs autotools
On Sat, 25 Nov 2017 00:20:38 + Peter Stuge 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
On Thu, 23 Nov 2017 16:36:07 + Peter Stuge 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
On Sun, 19 Nov 2017 22:27:26 -0500 Mike Gilbert 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
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
On Sun, 19 Nov 2017 16:49:51 + (UTC) Martin Vaeth wrote: > William L. Thomson Jr. 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
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." 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
Forgot something useful On Sat, 18 Nov 2017 09:50:51 -0500 "William L. Thomson Jr." 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
On Sat, 18 Nov 2017 14:11:11 + Roy Bamford 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 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 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." wrote: > On Thu, 16 Nov 2017 21:42:59 -0600 > Matthew Thode 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 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." 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
ption. > 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
avior 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 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 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." 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 wrote: > On Wed, Nov 15, 2017 at 3:21 PM, William L. Thomson Jr. > 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 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 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)
On Sat, 9 Sep 2017 11:45:23 +0800 (HKT) Brendan Horan 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
On Wed, 30 Aug 2017 14:01:08 -0400 "William L. Thomson Jr." 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 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." wrote: > On Thu, 7 Sep 2017 18:03:21 +0800 (HKT) > Brendan Horan 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" 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 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
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
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
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}
On Tue, 29 Aug 2017 23:40:11 +0100 James Le Cuirot 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}
On Tue, 29 Aug 2017 22:35:25 +0100 James Le Cuirot wrote: > # James Le Cuirot (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 wrote: > On Mon, Aug 14, 2017 at 5:26 PM, William L. Thomson Jr. > 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 wrote: > On Sat, Aug 12, 2017 at 9:50 AM, 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. > > > > 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&w=2&r=86&s=pms&q=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 wrote: > On Mon, Aug 14, 2017 at 2:42 PM, Peter Stuge 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 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 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 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
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
On Thu, 10 Aug 2017 13:33:54 +1000 "Sam Jorna (wraeth)" 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)" 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)" 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 wrote: > 2017-08-09 17:33 GMT+02:00 William L. Thomson Jr. : > > > On Wed, 9 Aug 2017 11:07:04 +1000 > > "Sam Jorna (wraeth)" 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)" 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)" wrote: > On 09/08/17 04:20, William L. Thomson Jr. wrote: > > On Tue, 8 Aug 2017 19:32:48 +0200 > > Kristian Fiskerstrand 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 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 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 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 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 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
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?
On Mon, 31 Jul 2017 12:56:18 +1000 Sam Jorna 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&l= 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+&l= 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?
On Mon, 31 Jul 2017 14:59:25 +0200 "Andreas K. Huettel" 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?
On Mon, 31 Jul 2017 10:28:31 +1000 Sam Jorna 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" 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)" wrote: > On 28 July 2017 8:44:20 PM AEST, "Andreas K. Huettel" > 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" wrote: > On 12/07/17 17:07, Gordon Pettey wrote: > > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. > > 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 wrote: > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. > 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] Sets vs Meta ebuilds
For everyone talking about -c vs -C. For the record, I never brought up removing packages in my sets discussion. That was an argument others were making against sets. It was 2 others seen below who mentioned the use of -C/--unmerge. For anyone telling me, I should be using -c vs -C. Why did you not say anything to them? They brought it up? They were the ones using? Yet no one spoke up to them as the have to me I was not discussing that. I rarely use such myself. I was just entertaining a discussion with others, their issues. Just for others to put the focus on me. It is all pretty funny! On Sat, 8 Jul 2017 20:27:38 -0400 "Walter Dnes" wrote: > > On Fri, 7 Jul 2017 12:57:17 -0400 > > Brian Evans wrote: > > > > Beware of sets.. if you put toolchain packages in a set and later > > do 'emerge --unmerge @custom-set' , emerge will happily destroy > > your toolchain. > > I tried "emerge -pv --unmerge @palemoon_build", and it was ready to > delete all the stuff, including gcc, etc. https://archives.gentoo.org/gentoo-dev/message/201cc1e7b5b878e3b28c3da1a41819e2 https://archives.gentoo.org/gentoo-dev/message/4ba8307a9dd5561cc1859a8c9546807a -- William L. Thomson Jr. pgpXoMeT71wJL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
On Thu, 13 Jul 2017 01:03:00 +1000 Sam Jorna wrote: > On 13/07/17 00:19, William L. Thomson Jr. wrote: > > 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 > > I'm not trying to be argumentative or antagonistic, I'm trying to > understand how your replacement warning differs from what's already > available and adds value. It is similar to the warnings that exist now. To my knowledge, other than generic messages that are always there, and a user is likely to ignore as noise. Nothing to my knowledge will tell you that someone was not removed because it a was a dependency. Neither -c, nor -C does this. I get -C maybe unware, but -c is not. Even when adding -v to -c, it does not explicitly say the package was not removed because another needs it. That is assumed, and IMHO the user is left wanting as previously stated. > $ emerge -C apg > * This action can remove important packages! In order to be safer, > use > * `emerge -pv --depclean ` to check for reverse dependencies > before > * removing packages. That is my point. That message is always there. The chance that it is ignored is very high. > Clearly, hence why I was trying to understand what difference your > proposal offered. But since we're moving on to serious things now, I > guess I /am/ done with this thread. I was proposing to provided further information to the user unique to that situation. Not removing because it is a dependency. -- William L. Thomson Jr. pgpPKYiZTWMxH.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)" 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)" 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)" 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)" 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)" 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 00:00:24 -0400 "William L. Thomson Jr." wrote: > 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. The whole purpose of this topic. I wanted to use sets in my custom profiles and I could not I did not want to mess with meta ebuilds. I make enough ebulids as it is. Maybe more than any other single.[1] Think about that? Why would I be messing with profiles, if I am dealing with things one off? I only am invoking emerge on things I am actively developing or packaging. The rest is handled via other means. I do appreciate all the lessons and instructions. Not sure when people will learn to stop assuming things about others. Many married couples barely know their spouse. You have no chance online 1. https://github.com/Obsidian-StudiosInc/os-xtoo/ -- William L. Thomson Jr. pgpD3cVAF1Mt8.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" 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" 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." 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 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 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 wrote: > On Mon, 10 Jul 2017 18:14:23 -0700 > Raymond Jennings 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 wrote: > On Tue, 11 Jul 2017 00:24:10 +0200 > Michał Górny 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