Re: [gentoo-user] eclean ... won't

2016-11-21 Thread Dale 
J. Roeleveld wrote:
> On Sunday, November 20, 2016 05:07:03 PM Константин wrote:
>> On Sun, Nov 20, 2016 at 01:35:46PM +, Peter Humphrey wrote:
>>> On Sunday 20 Nov 2016 16:05:29 Константин wrote:
 On Sun, Nov 20, 2016 at 09:42:40AM -0300, Zhu Sha Zang wrote:
> Maybe you need to use 'eclean-dist -d'. But, for your safe, use
> 'eclean-dist -dp' first.
 BTW what troubles can I get from 'eclean-dist -d' ? As far as I
 understand it, re-download needed tar.gz will be the worst isn't it?
>>> You'd think so, wouldn't you? But recently something has been going wrong
>>> here such that 'eclean-pkg -d' removed every single package, leaving just
>>> the directory structure. That was just after I'd spent six hours building
>>> them
>> Don't take me wrong it was not an objection but just a question. There
>> are a lot of warnigns, but no explanations except 'users will not be
>> protected in case they need to downgrade a package or re-install a
>> previously removed package.' or similar.
>>
>> And thanks for example.
> One example where this can be annoying is with packages that have fetch-
> restriction enabled. Or, even worse, where certain versions are no longer 
> available for download.
>
> --
> Joost
>
>


For those, you can use this option.

-f, --fetch-restrictedprotect fetch-restricted files (--deep only)

It only works with -d is the only problem I see with it.  It would be
nice if it would work for all of them. 

Dale

:-)  :-)

Re: [gentoo-user] eclean ... won't

2016-11-21 Thread J. Roeleveld 
On Sunday, November 20, 2016 05:07:03 PM Константин wrote:
> On Sun, Nov 20, 2016 at 01:35:46PM +, Peter Humphrey wrote:
> > On Sunday 20 Nov 2016 16:05:29 Константин wrote:
> > > On Sun, Nov 20, 2016 at 09:42:40AM -0300, Zhu Sha Zang wrote:
> > > > Maybe you need to use 'eclean-dist -d'. But, for your safe, use
> > > > 'eclean-dist -dp' first.
> > > 
> > > BTW what troubles can I get from 'eclean-dist -d' ? As far as I
> > > understand it, re-download needed tar.gz will be the worst isn't it?
> > 
> > You'd think so, wouldn't you? But recently something has been going wrong
> > here such that 'eclean-pkg -d' removed every single package, leaving just
> > the directory structure. That was just after I'd spent six hours building
> > them
> Don't take me wrong it was not an objection but just a question. There
> are a lot of warnigns, but no explanations except 'users will not be
> protected in case they need to downgrade a package or re-install a
> previously removed package.' or similar.
> 
> And thanks for example.

One example where this can be annoying is with packages that have fetch-
restriction enabled. Or, even worse, where certain versions are no longer 
available for download.

--
Joost

[gentoo-user] Battery plugin on fbpanel

2016-11-21 Thread William Ernesto Cárdenas Gómez 
Hello

I am testing fbpanel and generally I like it, but the battery plugin
does not work. The plugin only says "Running on AC No battery found"
I have been searching on the web but no solution to this problem.

¿Did anybody knows where to get or have info about this?

Re: [gentoo-user] bugs in ebuilds?

2016-11-21 Thread Jorge Almeida 
On Mon, Nov 21, 2016 at 2:09 PM, Neil Bothwick  wrote:
> On Mon, 21 Nov 2016 05:26:14 -0800, Jorge Almeida wrote:
>
>
>
> As a short term solution, you can run the application with nohup.
>
interesting. I was not familar with nohup. I could also redirect
stderr to /dev/null, but that would loose real error messages.

Thanx

Jorge

Re: [gentoo-user] bugs in ebuilds?

2016-11-21 Thread Neil Bothwick 
On Mon, 21 Nov 2016 05:26:14 -0800, Jorge Almeida wrote:

> My current concrete example: gtk+ 3.* has a configuration option
> --enable-debug=[no/minimum/yes] (default=debug_default)
> 
> There is no USE variable to control this. From what I [think I]
> understood, the default is set in the source file configure.ac, which
> sets debug_default to "yes"! This has the effect that it is impossible
> to launch gtk applications (e.g., zathura) from a terminal and still
> do something useful with the terminal, which gets spammed no-end with
> obnoxious messages about stuff the user cannot do anything about,
> anyway.

As a short term solution, you can run the application with nohup.


-- 
Neil Bothwick

Loose bits sink chips.


pgpHAMDHfbKp_.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] bugs in ebuilds?

2016-11-21 Thread Jorge Almeida 
On Mon, Nov 21, 2016 at 5:49 AM, Michael Orlitzky  wrote:
> On 11/21/2016 08:26 AM, Jorge Almeida wrote:
>> What is the proper procedure to ask for some modification in a ebuild?
>> (Bugs as well as feature requests...)
>>
>
> File a bug at https://bugs.gentoo.org/
>
Thanks. Done.

Re: [gentoo-user] bugs in ebuilds?

2016-11-21 Thread Michael Orlitzky 
On 11/21/2016 08:26 AM, Jorge Almeida wrote:
> What is the proper procedure to ask for some modification in a ebuild?
> (Bugs as well as feature requests...)
> 

File a bug at https://bugs.gentoo.org/


> My current concrete example: gtk+ 3.* has a configuration option
> --enable-debug=[no/minimum/yes] (default=debug_default)
> 
> There is no USE variable to control this...

It might make more sense to disable it unconditionally, but this is
perfectly appropriate for a bug. The bug wranglers will assign it to the
gnome team for you.

[gentoo-user] bugs in ebuilds?

2016-11-21 Thread Jorge Almeida 
What is the proper procedure to ask for some modification in a ebuild?
(Bugs as well as feature requests...)

My current concrete example: gtk+ 3.* has a configuration option
--enable-debug=[no/minimum/yes] (default=debug_default)

There is no USE variable to control this. From what I [think I]
understood, the default is set in the source file configure.ac, which
sets debug_default to "yes"! This has the effect that it is impossible
to launch gtk applications (e.g., zathura) from a terminal and still
do something useful with the terminal, which gets spammed no-end with
obnoxious messages about stuff the user cannot do anything about,
anyway.

If I'm not mistaken about the effect of --enable-debug, this
upstream-caused problem would be easily fixed for gentooers.


TIA


Jorge Almeida

Re: [gentoo-user] Re: vm still grinding away at compiling webkitgtk-2.14.2

2016-11-21 Thread John Covici 
On Mon, 21 Nov 2016 03:57:02 -0500,
Neil Bothwick wrote:
> 
> [1  ]
> On Mon, 21 Nov 2016 08:47:13 +, Peter Humphrey wrote:
> 
> > > On my i7 machine with 16g of ram, webkit-gtk has got to take 4/5 hours
> > > to compile.  This is using an ssd.  
> > 
> > That vindicates my choice of an NVMe SSD for this box, which is also an
> > i7 but with 32GB. Genlop shows it takes between 23 and 50 minutes here,
> > depending on what else I'm doing I suppose. What a difference a direct
> > connection makes!
> 
> There's more then the SSD to this. I get a similar result on my AMD9590
> box with an NVMe SSD, but my i5 laptop with 8GB and a SATA SSD takes
> "only" around 2-3 hours, on a system that should be significantly slower
> than John's.

Well, one other thing, I always do -j1 for the make options, too many
times things don't work right if I try higher numbers.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

Re: [gentoo-user] Re: vm still grinding away at compiling webkitgtk-2.14.2

2016-11-21 Thread Neil Bothwick 
On Mon, 21 Nov 2016 08:47:13 +, Peter Humphrey wrote:

> > On my i7 machine with 16g of ram, webkit-gtk has got to take 4/5 hours
> > to compile.  This is using an ssd.  
> 
> That vindicates my choice of an NVMe SSD for this box, which is also an
> i7 but with 32GB. Genlop shows it takes between 23 and 50 minutes here,
> depending on what else I'm doing I suppose. What a difference a direct
> connection makes!

There's more then the SSD to this. I get a similar result on my AMD9590
box with an NVMe SSD, but my i5 laptop with 8GB and a SATA SSD takes
"only" around 2-3 hours, on a system that should be significantly slower
than John's.


-- 
Neil Bothwick

Code: (n.) a means of concealing bugs favored by programmers.
  (v.) the process of concealing bugs by programming.


pgpLeZsx_leqs.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: vm still grinding away at compiling webkitgtk-2.14.2

2016-11-21 Thread Peter Humphrey 
On Sunday 20 Nov 2016 09:48:07 John Covici wrote:
> On Sun, 20 Nov 2016 09:25:58 -0500,
> 
> Harry Putnam wrote:
> > Rich Freeman  writes:
> > > IMO over-committing CPU isn't actually THAT bad.  The CPU obviously
> > > gets divided n ways, but that's as far as it goes.  There isn't that
> > > much overhead switching between VMs (though there certainly is some).
> > 
> > [...]
> > 
> > Thanks for the fuller picture and putting in the time to write it.
> 
> On my i7 machine with 16g of ram, webkit-gtk has got to take 4/5 hours
> to compile.  This is using an ssd.

That vindicates my choice of an NVMe SSD for this box, which is also an i7 but 
with 32GB. Genlop shows it takes between 23 and 50 minutes here, depending on 
what else I'm doing I suppose. What a difference a direct connection makes!

-- 
Regards
Peter