Re: [gentoo-dev] Empty project: Desktop

[Raymond Jennings]

I think that a superproject can serve as a good rubber-band grouping
construct, personlaly

On Thu, Aug 11, 2016 at 11:19 AM, Pacho Ramos  wrote:

> El jue, 11-08-2016 a las 13:15 +0300, Mart Raudsepp escribió:
> > [...]
> > It should be kept for the purposes of coordination between different
> > specific desktop projects and the grouping of them it provides as
> > subprojects.
> > However that doesn't mean it should have any packages in the tree
> > that
> > the desktop projects maintains itself personally, instead of one of
> > its
> > subprojects.
> >
> > One of my gentoo plans, when I have time, has been in reviving such
> > desktop-wide coordinations, possibly under the desktop project
> > banner.
> > E.g my started USE=gui and toolkit threads when I had time.
> >
> > Frankly, it would be weird to not have a project that broadly manages
> > all the desktop stuff.
> > We should manage this all better under a broad desktop project that
> > manages documentation, some policies, etc, but doesn't necessarily
> > have
> > any packages that it maintains in tree.
> >
> > If we need a new lead election per GLEP 39, I'm sure we have some
> > volunteers from the subprojects to throw their name in, that are
> > interested in having a good desktop-wide organization going on.
> > Myself
> > included.
> >
> >
> > Mart
> >
>
> Apart of me not understanding why are we reviving this that was already
> discussed when killing the old freedesktop-bugs herds in favor of the
> correct project, I don't think it makes sense to keep this concrete
> dead project for that potential and hypothetical changes that could
> benefit from it in the far future.
>
> Maybe when something of that is finally going to be done, we need that
> project and, in that case, you will be able of course to create your
> Project following the standard policy that allows to do that to any
> developers.
>
>
>

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Rich Freeman]

On Fri, Aug 12, 2016 at 1:48 PM, M. J. Everitt  wrote:
>
> I regret to say, although it's a well-known problem .. that the Gentoo
> bike-shed is never ever going to fall down - as the layers of paint
> applied will grossly outlive the materials it might once have been built
> from ... Perhaps someone might like to address the problem of the
> nuclear reactor which will otherwise never ever be functional ... ;)
>

Bikeshedding is only a problem if you let it be one.

Gentoo does not require unanimous consensus to get things done.  If
you choose to wait for it, and then complain about bikeshedding, then
YOU are the problem.

If I were James I would:

1.  Consider the advice given and propose the best way forward.
Indicate that I intend to commit the changes to the Gentoo repo in 48h
if there are no objections raised by QA or to Council.
2.  If there are no objections raised to Council or by QA then go
ahead with the commits, unless personally convinced by any further
arguments.
3.  If an objection was raised to QA, then comply with it for now, and
if in disagreement first work with QA, and appeal to Council if
necessary.
4.  If somebody appeals to Council, then let them make their case, and
offer my own, and await a decision.

If you do the above you'll never get in trouble, and you've basically
put the ball in somebody else's court if they want to hold you up.
Usually you won't delay your change by more than 48h, and if you do it
won't be by more than a month, unless the Council overrides you (in
which case you're "stuck" though presumably they would have good
reasons for doing so).

Some mistakes I see people make all the time:
1.  Give up as soon as a few devs make vocal complaints.  This is not
a shouting match.  The person with the most thread posts doesn't
automatically win the argument.
2.  Wait until everybody agrees.  While there are things everybody
agrees on, there aren't many of them.  I'm not sure the last sentence
even falls into that list of things everybody agrees on.  :)
3.  Plow forward without giving some time for appeals.  This can lead
to revert wars and such.
4.  Ignore official QA notices.  If a member of QA notifies you that
QA is taking action, you must comply until you resolve the issue with
QA or by appeal.
5.  Fail to work with QA.  The fact that a random QA member takes an
action doesn't mean that all of QA is necessarily behind it.  You may
find the issue resolved by spending 30 seconds on IRC.  The QA lead is
responsible to deal with these kinds of issues.
6.  Fail to let the Council clear roadblocks.  If you're trying to do
something, and you feel that something is blocking you, the Council
can help resolve that.

Devs get frustrated by bikeshedding because they're imposing rules and
limitations upon themselves that aren't actually community rules.  You
don't have to give up just because a few devs complain.  You ought to
listen, and if it is really controversial push for a decision.
However, strictly speaking if you have commit rights to the tree and
aren't violating a documented policy, then the onus is on others to
stop you, not for you to obtain permission to do something.  You
shouldn't abuse that, and hence I suggest giving people time to lodge
formal objections.  However, if you care about getting something done
it is completely fair to force those who wish to impede you to step up
and do the work to actively block you.  Devs don't have to prove the
"innocence" of each commit.

-- 
Rich

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Kent Fredric]

On Fri, 12 Aug 2016 12:40:38 -0500
james  wrote:

> Ok, show us a solution based on your dashed items

That's not what were doing here.

We have a bunch of different solutions with different trade-offs, and
whatever happens has to live with everything else.

And so we're discussing them, working out which one we're going to do.

> Nothing is stopping you, other than yourself of course

My point is more, clearly, you're the most motivated about this, surely
this means you're in more of a position to do something about it.

Its not on my list of immediate tasks, because a) It doesn't directly
interest me b) I have other pressing things to stress over.

I'm preoccupied with making things better within our current capacity
and features.

I don't have the resources to stretch our feature set and make things
more reliable in Gentoo at the same time :)

hth :)



pgpaTE6TIC1kT.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[M. J. Everitt]

On 12/08/16 18:40, james wrote:
> On 08/12/2016 10:39 AM, Kent Fredric wrote:
>> On Fri, 12 Aug 2016 09:12:22 -0500
>> james  wrote:
>>
>>> (also, I'm not hung up on 'Jentoo' as a name; perhaps 'Gintoo'?
>>>
>>> (peace && hth),
>>> James
>>
>> Way outside the scope needed here. However we pull off Zhenchoo, its
>> going to be built on top of portage and our package management with
>> extra bling.
>>
>> That's what is necessary to empower people with "ready built" machines
>> to customize it in the direction of a "natural gentoo install"
>>
>> All this converstation details is:
>>
>> - Is a given technique good
>> - Can it be installed in tree without breaking things
>> - How do we do that
>> - Is there a place we can do it where the problem is isolated to a
>>   narrow spectrum of users to limit potential fallout
>> - Is this a "Put warning bells on it and let users blow off their own
>>   feet and then don't do it by default"[1] thing.
>> - Can this be a "Just package.mask the problem on hardened" thing.
>>
>> All of those can be combined in some way to get and end result by
>> whoever ships the stage 4 the way they want to do it. They can use an
>> overlay if they want.
>>
>> Nothing is stopping them :)
>>
>> Other than themselves of course.
>>
>
> That simple huh?
>
> Ok, show us a solution based on your dashed items, for the current
> Valve/Steam/issues, and wrap up those very cool aforementioned games
> into a stage 4?
>
> I'd even settle for a liveDVD on that. Remember::
> Nothing is stopping you, other than yourself of course
>
>
> James
>
>
Kent's suggestions are quite valid, and indeed a good starting point for
anyone wishing to push their ideas forward (deliberately avoiding no
names at this point).

I can say that Kent is doing a stirling job supporting the Perl project
with an enormous amount of effort in keeping Perl current and valid for
the Gentoo distribution, and wouldn't be best placed to add to his
already full workload - we are all volunteers at the end of the day ..
or did someone forget that.

I regret to say, although it's a well-known problem .. that the Gentoo
bike-shed is never ever going to fall down - as the layers of paint
applied will grossly outlive the materials it might once have been built
from ... Perhaps someone might like to address the problem of the
nuclear reactor which will otherwise never ever be functional ... ;)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[james]

On 08/12/2016 10:39 AM, Kent Fredric wrote:

On Fri, 12 Aug 2016 09:12:22 -0500
james  wrote:


(also, I'm not hung up on 'Jentoo' as a name; perhaps 'Gintoo'?

(peace && hth),
James


Way outside the scope needed here. However we pull off Zhenchoo, its
going to be built on top of portage and our package management with
extra bling.

That's what is necessary to empower people with "ready built" machines
to customize it in the direction of a "natural gentoo install"

All this converstation details is:

- Is a given technique good
- Can it be installed in tree without breaking things
- How do we do that
- Is there a place we can do it where the problem is isolated to a
  narrow spectrum of users to limit potential fallout
- Is this a "Put warning bells on it and let users blow off their own
  feet and then don't do it by default"[1] thing.
- Can this be a "Just package.mask the problem on hardened" thing.

All of those can be combined in some way to get and end result by
whoever ships the stage 4 the way they want to do it. They can use an
overlay if they want.

Nothing is stopping them :)

Other than themselves of course.



That simple huh?

Ok, show us a solution based on your dashed items, for the current
Valve/Steam/issues, and wrap up those very cool aforementioned games 
into a stage 4?


I'd even settle for a liveDVD on that. Remember::
Nothing is stopping you, other than yourself of course


James

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Kent Fredric]

On Fri, 12 Aug 2016 09:12:22 -0500
james  wrote:

> (also, I'm not hung up on 'Jentoo' as a name; perhaps 'Gintoo'?
> 
> (peace && hth),
> James

Way outside the scope needed here. However we pull off Zhenchoo, its
going to be built on top of portage and our package management with
extra bling.

That's what is necessary to empower people with "ready built" machines
to customize it in the direction of a "natural gentoo install"

All this converstation details is:

- Is a given technique good
- Can it be installed in tree without breaking things
- How do we do that
- Is there a place we can do it where the problem is isolated to a
  narrow spectrum of users to limit potential fallout
- Is this a "Put warning bells on it and let users blow off their own
  feet and then don't do it by default"[1] thing.
- Can this be a "Just package.mask the problem on hardened" thing.

All of those can be combined in some way to get and end result by
whoever ships the stage 4 the way they want to do it. They can use an
overlay if they want.

Nothing is stopping them :)

Other than themselves of course.


pgpDC9uWDHgay.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[james]

On 08/11/2016 07:32 PM, Kent Fredric wrote:

On Thu, 11 Aug 2016 17:27:14 -0700
Patrick McLean  wrote:


 It's not like there is a shortage of
packages that install crappy crap on your system...


In this instance I agree that we're kinda stressing about the wrong
thing.

But I can't support that reasoning.

"There is bad stuff in tree so why not have more" is not a great line
of reasoning.

We want things to be *better*, we should shy away from that reasoning.

The *reason* here is "user choice".

As much as Gentoo developers may have problems with steam, user-choice
orientation dictates we should at least consider supporting it in some
regard, and if we can do so without affecting the people who don't want
steam, we should also strive to do that.

And we *can*.

That's why its better as an independent thing, not as core mechanics in
libpcre.



One possible solution, is to realize that everyone is right from their 
perspective. OK. Then how do *we* find an acceptable solution set? Well, 
this is not the first time and it's occurring more and more frequently 
in gentoo, from my perspective, that our ying-n-yang of secure vs 
innovation is pulling the devs apart.


1. We do need an extraordinarily (think hardened++) secure gentoo, as 
the nefarious activities of interlopers is becoming an avalanche on 
computing and networking (Think Zener (or avalance) diode). [1]
A few quick and easy, stage-4 offerings for common needs, would be a 
strong recruiting tool for gentoo. ymmv.



[1] https://en.wikipedia.org/wiki/Avalanche_diode

Certainly QA is part of that solution, and those folks are 100% correct.

2. Gentoo needs to have a version (jentoo?) so that we can return  to 
raw innovation, of anything and everything any technoid wants to pursue.
To me, that was and is the heart and soul of gentoo; but that postulate 
alone wreaks of multifaceted danger. (danger Will Robinson, danger!). 
Still my needs and heart is with these innovative folks, 100%, and yes 
it is due to my new found addiction to all things clusterd.



So, how about we use (VMs/Container/unikernels/embedded/approaches>) to allow both to coexist on the same hardware? Now, whether
Gentoo(hardened) is the main host and Jentoo(the latest innovation) is 
the VM  or vice-versa, remains to be explored and proven and provided as 
a choice. Deeply embedded, hardened-gentoo, located on a usb stick, does 
appeal to many different uses and it can be quickly unplugged by the 
local admin, as an added fail-safe feature. Choice is preeminent, imho.



I'd like to see Jentoo, become the most innovative platform in the 
entire FOSS world, as gentoo once was.  For now, they (Gentoo and 
Jentoo) could be run on different (hardware) systems and combined later, 
when viable mechanisms are proposed, tested and vetted. This thread of 
consternation only servers to 'yet again' validate both needs. Jentoo 
could live out of an alternative repo, and the rules for putting codes 
in there, are managed by the devs that favor innovation over 
constriction. In fact, we could also experiment with an open source 
alternative (gitlab?) in lieu of github (just a thought, do not get your 
panties in a bunch over this)?



Gentoo, does need a 'tight-assed', secure and reliability first mantra 
to move forward to serve the computational worlds needs. Security is at 
a breaking point, imho; hacker news has a posting about systemd and 
buntu in full meltdown related to (server)clusters. Furthermore, 
nation-states have a vesting interest in taxing the productive for a 
variety of reasons, and network/computing/communications instability is 
the new 'cold war' where excessive taxes, robber-barron greed, and 
globalization are converging towards war(3). So do not look to 
governments or the globalist to prevent war. I'm not certain that gentoo 
can prevent this, but it's worth a little effort, no?



If we can make a secure peace with both the innovative and the secure 
camps, within Gentoo (and Jentoo), then perhaps the computational world 
will follow our lead. Vendors (greeds) are going to plunge us into WW3, 
if folks do not 'wise up' and 'pull together'.


(also, I'm not hung up on 'Jentoo' as a name; perhaps 'Gintoo'?

(peace && hth),
James

Re: [gentoo-dev] Empty project: LXDE

[Tom H]

On Wed, Aug 10, 2016 at 10:16 PM, james  wrote:
> On 08/10/2016 04:07 PM, Tom H wrote:
>>
>> If LXQT's too bloated for you, try Lumina:
>>
>> https://lumina-desktop.org/
>>
>> There's an ebuild.
>
> I did a quick search and did not find a comparison of lumina to lxqt.
> I'd like to see a feature comparison to lxqt; gotta ref on the
> comparison?
>
> thx Tom,

You're welcome.

Sorry, I have no refs. There may not be a head-to-head comparison and
it might make sense because Lumina's more of a WM+ than a DE.

Re: [gentoo-dev] libfm requires dbus-glib to build, but it is not listed as a dependency.

[Kent Fredric]

On Fri, 12 Aug 2016 10:57:53 +0100
malc  wrote:

> You will want to report that on bugs.gentoo.org, providing the
> suggested emerge info etc. please :)
> The reference at [1] is your friend.
> 
> Cheers,
> malc.
> 

I agree, a bugzilla bug is usaully better.

Though I am somewhat of the opinion that if people only reached as far
as to report it via email, we should accept it in that form and do the
rest ourselves.

Some people, myself included, hate signing up for things on a regular
basis.

And email is thus simply another way people can engage in opensource
freely.

Additional barriers and requirements are not required here.

Its already cost both of us combined more effort than relaying the bug
ourselves ;) 

As it happens, a bug meeting the OPs' description was already filed
last September, and its maintainers just haven't gotten around to
fixing it yet.

https://bugs.gentoo.org/show_bug.cgi?id=560586

So this time, an additional bug is not required to be opened :)


pgpyvA99sziye.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] libfm requires dbus-glib to build, but it is not listed as a dependency.

[malc]

You will want to report that on bugs.gentoo.org, providing the suggested
emerge info etc. please :)
The reference at [1] is your friend.

Cheers,
malc.

[1] https://wiki.gentoo.org/wiki/Bugzilla/Guide


On Fri, Aug 12, 2016 at 5:58 AM,  wrote:

> The title pretty much explains it all. I did a clean install using the
> generic desktop profile and went on to build lxqt. The build failed with
> libfm which complained of dbus-glib not being found. A quick emerge of
> dbus-glib resolved the issue.
>
> this would be libfm-1.2.3-r1
>
>