[gentoo-user] Re: dynamic deps, wtf are they exactly
Rich Freeman wrote: > > Sure, but the portage team can really only dictate the upstream > defaults of portage, not tree policy. As I understand, they intend to remove non-dynamic deps (if they agreed to not implement it properly for sub-slots, this makes sense). So we are not speaking about defaults but a fixed behaviour of portage. Paludis had this fixed behaviour since ever. Thus, esssentially, there is no other choice than to adopt the necessary tree policy to the only existing implementations - not council decision is needed for it unless there are package managers which do it differently. Note that there can really be no exceptions. Even apparently trivial changes in DEPS like adding an alternative implementation *necessarily* require a revbump (because otherwise users who installed the previous ebuild could possibly never get rid of the original implementation). We will see a flood of "unnecessary" revbumps, but people knew this since the previous discussions.
Re: [gentoo-user] CMYK comparison to sRGB between platforms
On Sunday 27 September 2015 12:36:27 Mick wrote: > Contributing is more involved than simply downloading a profile. I think > you have to use the TaxiDB API: > > http://sourceforge.net/p/openicc/taxi/ci/master/tree/docs/api_doc.txt Hm. I see what you mean. > I you are interested then you can contact the OpenICC project to ask for > details: > > http://www.freedesktop.org/wiki/OpenIcc/ I'll go and explore a bit, and report back if I find anything interesting. -- Rgds Peter
Re: [gentoo-user] Re: dynamic deps, wtf are they exactly
On Mon, Sep 28, 2015 at 3:57 AM, Martin Vaeth wrote: > Rich Freeman wrote: >> >> Sure, but the portage team can really only dictate the upstream >> defaults of portage, not tree policy. > > As I understand, they intend to remove non-dynamic deps > (if they agreed to not implement it properly for sub-slots, > this makes sense). > > So we are not speaking about defaults but a fixed behaviour of > portage. Paludis had this fixed behaviour since ever. > Thus, esssentially, there is no other choice than to adopt the > necessary tree policy to the only existing implementations - > not council decision is needed for it unless there are package > managers which do it differently. Like I said, we can either have a formal decision, or listen to everybody fight WW3 over it for three years. What is the value in doing the latter? The fact that none of the package managers work with a tree practice won't stop developers from doing it anyway. Plus, any of them can just fork portage and put that in the tree - there is no policy that states that there can be only one implementation of portage. Heck, they could just follow the same upstream and patch it in the ebuild. People seem to think that just going and imposing a change on everybody else without their input somehow makes things more efficient, or less political. The reality is that it just results in more politics, since many will not accept the validity of their actions. It also isn't how we do things around here. If you want to change tree policy, propose it on a list, let everybody have their say, and then if necessary let the council impose a decision. People might not like the decision, but most devs will at least respect the legitimacy of it. If they don't respect the decision they can be booted, and the council will back that up. This isn't about who is or isn't right, or whether the portage team knows what they're doing. This is about having a process (GLEP 39) and following it. The portage team can do whatever they want with portage (after all, nobody has to use portage), but if they want to change what everybody else is doing with their ebuilds they have to follow the process. -- Rich
Re: [gentoo-user] dynamic deps, wtf are they exactly
--Original Message-- From: Michael Orlitzky To: gentoo-user@lists.gentoo.org ReplyTo: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] dynamic deps, wtf are they exactly Sent: Sep 27, 2015 5:21 PM On 09/27/2015 03:34 PM, Alan McKinnon wrote: > > Now it all makes sense, as a bonus I now see why why so many senior devs > are so pedantic about revbumps (they have reason). > > Now that I know what the symptom will be, are bug reports useful? > I don't think most developers are aware of the problem, so if you point out that the lack of a revbump causes pain, many will be glad to know and adjust their behavior. Or, you might just get yelled at. It's one of /those/ issues. Sent from my Verizon Wireless BlackBerry
[gentoo-user] process takes about 85% of the CPU
when I run htop I see a process that takes about 85% of the CPU: Why is it taking so much CUP? /usr/bin/X -nolisten tcp -br -deferglyphs 16 vt07 -auth /var/run/slim.auth Yes, I use slim to login. -- Thelma
Re: [gentoo-user] update problems
Alan McKinnon writes: > On 27/09/2015 21:17, lee wrote: > > > > [big snip] > >>> Seems to me you are thinking like a human (because you are one) and not >>> > seeing portage's limits. Portage has no idea what would solve the issue >>> > so can't give any recommendations worth a damn. The best it can do is >>> > print some hardcoded logic that looks like it might apply. >> According to that, the human is even less able to figure out what might >> solve the problem than portage is: The human doesn't know anything about >> the huge number of dependencies involved, and even if they did, it would >> take them really really long to go through all of them to figure out >> anything at all. Now if they do it right, the human would come to the >> same conclusion as portage, provided that portage does it right. >> > > [big snip] > > Fellow, I'm done with you, really. > > You hold onto your issues with portage like they were some treasured > memory of a long-since departed loved one, while all the time apparently > ignoring the correct valid solutions offeered by kind folks on this list. > > Let it go. The devs know about portage output. I don't see you > submitting patches though. You ran out of arguments and remain at insisting that the problem is known and cannot be fixed because it's too complicated while rejecting suggestions but asking for patches. So I have no reason to think that patches would be any more welcome than suggestions, and now even if you came up with some pointer what to look at (since emerge, for example, is a wrapper script from which I couldn't see where to start), I wouldn't waste my time with it. Congratulations. -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
Re: [gentoo-user] update problems
On Tue, Sep 29, 2015 at 12:52:41AM +0200, lee wrote: > > Alan McKinnon writes: > > > On 27/09/2015 21:17, lee wrote: > > > > Fellow, I'm done with you, really. > > > > You hold onto your issues with portage like they were some treasured > > memory of a long-since departed loved one, while all the time apparently > > ignoring the correct valid solutions offeered by kind folks on this list. > > > > Let it go. The devs know about portage output. I don't see you > > submitting patches though. > > You ran out of arguments and remain at insisting that the problem is > known and cannot be fixed because it's too complicated while rejecting > suggestions but asking for patches. So I have no reason to think that > patches would be any more welcome than suggestions, and now even if you > came up with some pointer what to look at (since emerge, for example, is > a wrapper script from which I couldn't see where to start), I wouldn't > waste my time with it. Congratulations. > Someone (I can't remember who, probably Rich Freeman or some other dev) described a problem with the general process of fixing the portage output a while ago. I believe the steps went something like this: 1. Think the portage output sucks 2. Learn what the output means 3. Lose all motivation to improve the output because it is no longer necessary for you The portage output is not as good as it could be, but everyone with the knowledge to fix it doesn't because they neither care (because they understand it) *nor* are they being paid. In my opinion, the portage output is not that bad, in the same way that gcc's error messages are not that bad. They can be difficult to get used to and some of them are absolutely ridiculous, but after using gcc for a while they almost always make sense and are precise. Alec
Re: [gentoo-user] update problems
On Tue, 29 Sep 2015 00:52:41 +0200, lee wrote: > > You hold onto your issues with portage like they were some treasured > > memory of a long-since departed loved one, while all the time > > apparently ignoring the correct valid solutions offeered by kind > > folks on this list. > > > > Let it go. The devs know about portage output. I don't see you > > submitting patches though. > > You ran out of arguments This thread ran out of arguments a long time ago. Repeating the same ones doesn't count. > and remain at insisting that the problem is > known and cannot be fixed because it's too complicated It's not that it cannot be fixed, just that it is very difficult to do what you "just" want. > while rejecting > suggestions but asking for patches. So I have no reason to think that > patches would be any more welcome than suggestions, Patches are always more welcome than suggestions. "Fix it!" is never as welcome as "here's how". I think it was Canek who said "code talks". > and now even if you > came up with some pointer what to look at (since emerge, for example, is > a wrapper script from which I couldn't see where to start), Really? The first few lines of the script tell you where the real scripts are? The wrapper seems to be there to deal with different default Python versions. > I wouldn't waste my time with it. Then why on Earth would you expect the devs to do it for you with that attitude? Adding the word "just" to a demand does not make the task any simpler, nor does it increase your chances of getting what you want. On the contrary, it serves to illustrate that you do not grasp the complexity of the situation. -- Neil Bothwick Three kinds of people: those who can count and those who can't. pgppcNG6DDejN.pgp Description: OpenPGP digital signature
