Re: [gentoo-user] Not enough RAM for dev-qt/qtwebengine build

2019-06-15 Thread Dale
Alec Ten Harmsel wrote:
> On Sat, Jun 15, 2019, at 14:19, Walter Dnes wrote:
>> On Thu, Jun 13, 2019 at 05:15:41PM +0300, Alexey Eschenko wrote
>>> Thank you. Didn't think about that. Don't know why though. My
>>> MAKEOPTS was "-j32". Looks like that was too many for package like
>>> qtwebengine. Solved the problem with creating specific environment
>>> for qtwebengine and setting it up in /etc/portage/package.env/ It was
>>> vry long build process but this time it finished successfully. I
>>> think I'll try to find more appropriate value for qtwebengine which
>>> could be used with 32GB of RAM.
>>   Please use plain text, not HTML.
>>
>>   According to
>> https://blogs.gentoo.org/ago/2013/01/14/makeopts-jcore-1-is-not-the-best-optimization/
>> the fastest compiles come with setting MAKEOPTS to the number of cores
>> in your machine.  E.g. for a dual core cpu, use "-j2", for a 4 core cpu
>> use "-j4", etc.  To check the number of cpus in your machine, execute...
>>
>> grep -c ^flags /proc/cpuinfo
> That's a good rule but not necessarily always true. My old machine was an 
> i7-3930K (6 cores, 12 threads) w/ 32G RAM. I had /var/tmp on tmpfs. I 
> benchmarked firefox, chromium, and some other big projects once and -j13 was 
> consistently the fastest on that box.
>
> As that blog post says:
>
>> I’m just saying, ${core} + 1 is not the best optimization for me
>> and the test confirms the part:“but this guideline isn’t always perfect”
> Depends on available RAM, how fast your disk is, etc.
>
> Alec
>
>


As a AMD CPU user, I always set mine to number of cores plus one.  That
seems to always be the most efficient for me.  I have portages work
directory on tmpfs for all but a couple large packages.  I used to make
exceptions for Firefox, Seamonkey, Libreoffice and qtweb something or
other.  Since I upgraded my memory to 32GBs I removed all but
Libreoffice.  My biggest problem was when more than one of those wanted
to compile at the same time. 

The best way to know what to set it to, test it.  Set it to cores plus
one and test.  Then set it to half the number of cores, twice the number
of cores etc until you find that sweet spot.  One could even do that
during normal updates although it may not be as accurate.  I suspect if
ten people with ten different systems tested this, we'd get half a dozen
different results, maybe more. 

The best thing in my opinion, start emerge, go to bed and then hope it
is done when you wake up.  lol 

Dale

:-)  :-)



Re: [gentoo-user] Not enough RAM for dev-qt/qtwebengine build

2019-06-15 Thread Alec Ten Harmsel
On Sat, Jun 15, 2019, at 14:19, Walter Dnes wrote:
> On Thu, Jun 13, 2019 at 05:15:41PM +0300, Alexey Eschenko wrote
> > Thank you. Didn't think about that. Don't know why though. My
> > MAKEOPTS was "-j32". Looks like that was too many for package like
> > qtwebengine. Solved the problem with creating specific environment
> > for qtwebengine and setting it up in /etc/portage/package.env/ It was
> > vry long build process but this time it finished successfully. I
> > think I'll try to find more appropriate value for qtwebengine which
> > could be used with 32GB of RAM.
> 
>   Please use plain text, not HTML.
> 
>   According to
> https://blogs.gentoo.org/ago/2013/01/14/makeopts-jcore-1-is-not-the-best-optimization/
> the fastest compiles come with setting MAKEOPTS to the number of cores
> in your machine.  E.g. for a dual core cpu, use "-j2", for a 4 core cpu
> use "-j4", etc.  To check the number of cpus in your machine, execute...
> 
> grep -c ^flags /proc/cpuinfo

That's a good rule but not necessarily always true. My old machine was an 
i7-3930K (6 cores, 12 threads) w/ 32G RAM. I had /var/tmp on tmpfs. I 
benchmarked firefox, chromium, and some other big projects once and -j13 was 
consistently the fastest on that box.

As that blog post says:

> I’m just saying, ${core} + 1 is not the best optimization for me
> and the test confirms the part:“but this guideline isn’t always perfect”

Depends on available RAM, how fast your disk is, etc.

Alec



Re: [gentoo-user] Not enough RAM for dev-qt/qtwebengine build

2019-06-15 Thread Walter Dnes
On Thu, Jun 13, 2019 at 05:15:41PM +0300, Alexey Eschenko wrote
> Thank you. Didn't think about that. Don't know why though. My
> MAKEOPTS was "-j32". Looks like that was too many for package like
> qtwebengine. Solved the problem with creating specific environment
> for qtwebengine and setting it up in /etc/portage/package.env/ It was
> vry long build process but this time it finished successfully. I
> think I'll try to find more appropriate value for qtwebengine which
> could be used with 32GB of RAM.

  Please use plain text, not HTML.

  According to
https://blogs.gentoo.org/ago/2013/01/14/makeopts-jcore-1-is-not-the-best-optimization/
the fastest compiles come with setting MAKEOPTS to the number of cores
in your machine.  E.g. for a dual core cpu, use "-j2", for a 4 core cpu
use "-j4", etc.  To check the number of cpus in your machine, execute...

grep -c ^flags /proc/cpuinfo

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications



Re: [gentoo-user] UEFI kernel installation?

2019-06-15 Thread Mick
On Saturday, 15 June 2019 14:04:16 BST Peter Humphrey wrote:
> Hello list,
> 
> The main system on this box is ~amd64 plasma, but I also have a small rescue
> system which is amd64, no desktop. I use bootctl from systemd-boot to
> manage the UEFI images.
> 
> My question is: how much of the bootctl-installed image is essential for
> booting? In other words, if I install the ~amd64 kernel (5.1.9), what effect
> will that have on booting the rescue system; and if I install the amd64
> kernel (4.19.44), what effect will it have on booting the plasma system?
> 
> In practice, I install the ~amd64 kernel and hope it doesn't affect the
> rescue system too much; and it seems not to. Could I do better?

Assuming I've understood correctly your question, since this is the same box 
and both kernels will be booting the same hardware, with similar modules, it 
shouldn't make any odds what OS installation you decide to boot into with any 
of two given kernels.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] UEFI kernel installation?

2019-06-15 Thread J. Roeleveld
On June 15, 2019 1:04:16 PM UTC, Peter Humphrey  wrote:
>Hello list,
>
>The main system on this box is ~amd64 plasma, but I also have a small
>rescue 
>system which is amd64, no desktop. I use bootctl from systemd-boot to
>manage 
>the UEFI images.
>
>My question is: how much of the bootctl-installed image is essential
>for 
>booting? In other words, if I install the ~amd64 kernel (5.1.9), what
>effect 
>will that have on booting the rescue system; and if I install the amd64
>kernel 
>(4.19.44), what effect will it have on booting the plasma system?
>
>In practice, I install the ~amd64 kernel and hope it doesn't affect the
>rescue 
>system too much; and it seems not to. Could I do better?

If you configure the kernel with EFI boot, you can also ignore the boot loader.
I use "systemd-boot", which basically is "gummiboot" on my laptop to be able to 
select which kernel to boot.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



[gentoo-user] UEFI kernel installation?

2019-06-15 Thread Peter Humphrey
Hello list,

The main system on this box is ~amd64 plasma, but I also have a small rescue 
system which is amd64, no desktop. I use bootctl from systemd-boot to manage 
the UEFI images.

My question is: how much of the bootctl-installed image is essential for 
booting? In other words, if I install the ~amd64 kernel (5.1.9), what effect 
will that have on booting the rescue system; and if I install the amd64 kernel 
(4.19.44), what effect will it have on booting the plasma system?

In practice, I install the ~amd64 kernel and hope it doesn't affect the rescue 
system too much; and it seems not to. Could I do better?

-- 
Regards,
Peter.






[gentoo-user] Re: Gvim icon problem

2019-06-15 Thread Nikos Chantziaras

On 15/06/2019 12:00, Philip Webb wrote:

I've just upgraded to Gvim 8.1.1486 & most of the icons have disappeared.
Attached are screenshots before/after, "before" from a desktop still running.

Does anyone know how to fix this ?


Is kde-plasma/kde-gtk-config installed? If not, install it. Then open 
the KDE "System Settings", and go to "Application Style". Select 
"GNOME/Gtk Application Style". Make sure "Icon Theme" is set to "Breeze" 
and "Fallback theme" is set to "Adwaita". If there's no "Adwaita" 
option, then emerge x11-themes/adwaita-icon-theme.


You might need to logout and login for changes to take effect.




[gentoo-user] Re: i don't see icu

2019-06-15 Thread Nikos Chantziaras

On 15/06/2019 11:57, Philip Webb wrote:

For a long time, I've been having a problem upgrading 'icu'.
There seems to be a conflict with KDE :

   !!! Multiple package instances within a single package slot have been pulled
   !!! into the dependency graph, resulting in a slot conflict:

   dev-libs/icu:0

   (dev-libs/icu-64.2:0/64.2::gentoo, ebuild scheduled for merge) pulled in by
 dev-libs/icu (Argument)

   (dev-libs/icu-60.2:0/60.2::gentoo, installed) pulled in by
   dev-libs/icu:0/60.2= required by 
(dev-qt/qtwebkit-5.212.0_pre20180120:5/5.212::gentoo, installed)
   


I get something like that from time to time. What I do is to back up the 
current ICU with:


quickpkg dev-libs/icu

so that I can quickly install it again if something doesn't work later 
on. Reinstalling it from the above created binary package is done with:


emerge -a1K dev-libs/icu

(The "K" is important, otherwise it will re-built ICU instead of just 
installing from the backup binary package.)


Then I unmerge it:

emerge -aC dev-libs/icu

And then I run the @world upgrade again and see if portage is now able 
to figure it out.







[gentoo-user] Gvim icon problem

2019-06-15 Thread Philip Webb
I've just upgraded to Gvim 8.1.1486 & most of the icons have disappeared.
Attached are screenshots before/after, "before" from a desktop still running.

Does anyone know how to fix this ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca



[gentoo-user] i don't see icu

2019-06-15 Thread Philip Webb
For a long time, I've been having a problem upgrading 'icu'.
There seems to be a conflict with KDE :

  root:577 ~> USE="nls" emerge --backtrack=30 -pv icu 
  These are the packages that would be merged, in order:
  Calculating dependencies... done!
  [ebuild  r  U  ] dev-libs/icu-64.2:0/64.2::gentoo [60.2:0/60.2::gentoo] 
USE="-debug -doc -examples -static-libs" ABI_X86="-32 (64) (-x32)" 23,451 KiB
  [ebuild  rR] dev-db/sqlite-3.28.0:3::gentoo  USE="-debug -doc icu 
readline secure-delete -static-libs -tcl -test -tools" ABI_X86="-32 (64) 
(-x32)" 0 KiB
  [ebuild  rR] dev-qt/qtcore-5.12.3:5/5.12::gentoo  USE="-debug icu 
-systemd -test" 0 KiB
  [ebuild  rR] dev-libs/libxml2-2.9.9-r1:2::gentoo  USE="-debug -examples 
icu -ipv6 -lzma python readline -static-libs -test" ABI_X86="-32 (64) (-x32)" 
PYTHON_TARGETS="python2_7 -python3_5 python3_6 (-python3_7)" 0 KiB
  [ebuild  rR] dev-libs/boost-1.65.0:0/1.65.0::gentoo  USE="-context -debug 
-doc icu -mpi nls python -static-libs threads -tools" ABI_X86="-32 (64) (-x32)" 
PYTHON_TARGETS="python2_7 (-python3_4%) -python3_5 python3_6" 0 KiB
  [ebuild  rR] media-libs/libvisio-0.1.6::gentoo  USE="-doc -static-libs 
-test -tools" 0 KiB
  [ebuild  rR] media-libs/libcdr-0.1.5::gentoo  USE="-doc -static-libs 
-test" 0 KiB
  [ebuild  rR] app-text/libqxp-0.0.2::gentoo  USE="-debug -doc -test 
-tools" 0 KiB
  [ebuild  rR] media-libs/libzmf-0.0.2::gentoo  USE="-debug -doc -test 
-tools" 0 KiB
  [ebuild  rR] app-text/libmspub-0.1.4::gentoo  USE="-doc -static-libs" 0 
KiB
  [ebuild  rR] app-text/libebook-0.1.2-r1::gentoo  USE="-doc -test -tools" 
0 KiB
  [ebuild  rR] media-libs/raptor-2.0.15-r2:2::gentoo  USE="curl -debug 
-json -static-libs unicode" 0 KiB
  [ebuild  rR] media-libs/harfbuzz-2.3.1:0/0.9.18::gentoo  USE="cairo 
-debug glib graphite icu -introspection -static-libs -test truetype" 
ABI_X86="-32 (64) (-x32)" 0 KiB
  [ebuild  rR] app-office/libreoffice-6.2.4.2::gentoo  USE="accessibility 
-bluetooth -branding (-coinmp) cups dbus -debug -eds (-firebird) -googledrive 
-gstreamer gtk gtk2 -java -kde -ldap -mariadb -odk pdfimport -postgres -test 
-vlc" LIBREOFFICE_EXTENSIONS="-nlpsolver -scripting-beanshell 
-scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="-python2_7 
-python3_5 python3_6 (-python3_7)" PYTHON_TARGETS="python2_7 -python3_5 
python3_6 (-python3_7)" 0 KiB

  Total: 14 packages (1 upgrade, 13 reinstalls), Size of downloads: 23,451 KiB

  !!! Multiple package instances within a single package slot have been pulled
  !!! into the dependency graph, resulting in a slot conflict:

  dev-libs/icu:0

  (dev-libs/icu-64.2:0/64.2::gentoo, ebuild scheduled for merge) pulled in by
dev-libs/icu (Argument)

  (dev-libs/icu-60.2:0/60.2::gentoo, installed) pulled in by
  dev-libs/icu:0/60.2= required by 
(dev-qt/qtwebkit-5.212.0_pre20180120:5/5.212::gentoo, installed)
  

-- end of output --

I don't need 'USE="nls"', but otherwise there's anothe conflict with 'boost'.
'icu' provides "international components for Unicode" :
whyever is that simple stuff running into this problem ?

Any suggestions welcome.

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca