[gentoo-user] gst-plugins blocker
I see that =media-libs/gst-plugins-base-1.4:1.0 required by (net-libs/ farstream-0.2.8-r1:0.2/5::gentoo, ebuild scheduled for merge) >=media-libs/gst-plugins- base-1.10.5:1.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] (>=media-libs/gst-plugins-base-1.10.5:1.0[abi_x86_64(-)]) required by (media- libs/gst-plugins-good-1.10.5:1.0/1.0::gentoo, ebuild scheduled for merge) media-libs/gst-plugins-base: 1.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] (media-libs/gst-plugins-base:1.0[abi_x86_64(-)]) required by (media-plugins/ gst-plugins-libnice-0.1.13-r100:1.0/1.0::gentoo, ebuild scheduled for merge) >=media-libs/gst-plugins- base-1.10.5:1.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?,introspection?] (>=media-libs/gst-plugins-base-1.10.5:1.0[abi_x86_64(-),introspection]) required by (media-libs/gst-plugins-bad-1.10.5:1.0/1.0::gentoo, ebuild scheduled for merge) (media-libs/gst-plugins-bad-1.10.5:1.0/1.0::gentoo, ebuild scheduled for merge) pulled in by >=media-libs/gst-plugins-bad-1.4:1.0 required by (net-libs/ farstream-0.2.8-r1:0.2/5::gentoo, ebuild scheduled for merge) = -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] gst-plugins blocker
On 21/11/2017 15:03, Mick wrote:
> I see that plugins-base-1.12.3, so I removed various gst-plugins and net-libs/farstream,
> emerged -1 media-libs/gst-plugins-base-1.12.3, but portage continues to
> complain, with backtrack=99 or not.
>
> What is the way to overcome this?
>
> =
> # emerge @preserved-rebuild -v -a
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild N ] media-libs/gst-plugins-bad-1.10.5:1.0::gentoo USE="X bzip2
> egl introspection nls opengl orc vnc wayland -gles2 -gtk {-test} -vcd"
> ABI_X86="(64) -32 (-x32)" 0 KiB
> [ebuild N ] media-plugins/gst-plugins-libnice-0.1.13-r100:1.0::gentoo
> ABI_X86="(64) -32 (-x32)" 0 KiB
> [ebuild N ] media-libs/gst-plugins-good-1.10.5:1.0::gentoo USE="nls
> orc"
> ABI_X86="(64) -32 (-x32)" 0 KiB
> [ebuild N ] net-libs/farstream-0.2.8-r1:0.2/5::gentoo
> USE="introspection
> {-test} -upnp" 0 KiB
> [ebuild R] net-im/pidgin-2.12.0:0/2::gentoo USE="dbus gstreamer gtk
> ncurses nls spell xscreensaver (-aqua) -debug -doc -eds -gadu -gnutls -
> groupwise -idn -meanwhile -networkmanager -perl -pie -prediction -python
> -sasl
> -silc -tcl -tk -zephyr -zeroconf" PYTHON_TARGETS="python2_7" 0 KiB
> [blocks B ] plugins-bad-1.11.90:1.0" is blocking media-libs/gst-plugins-base-1.12.3)
>
> Total: 5 packages (4 new, 1 reinstall), Size of downloads: 0 KiB
> Conflict: 1 block (1 unsatisfied)
>
> * Error: The above package list contains packages which cannot be
> * installed at the same time on the same system.
>
> (media-libs/gst-plugins-base-1.12.3:1.0/1.0::gentoo, installed) pulled in by
> media-libs/gst-plugins-base:1.0 required by (net-im/
> pidgin-2.12.0:0/2::gentoo, ebuild scheduled for merge)
> >=media-libs/gst-plugins-base-1.4:1.0 required by (net-libs/
> farstream-0.2.8-r1:0.2/5::gentoo, ebuild scheduled for merge)
> >=media-libs/gst-plugins-
> base-1.10.5:1.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]
>
> (>=media-libs/gst-plugins-base-1.10.5:1.0[abi_x86_64(-)]) required by (media-
> libs/gst-plugins-good-1.10.5:1.0/1.0::gentoo, ebuild scheduled for merge)
> media-libs/gst-plugins-base:
> 1.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]
>
> (media-libs/gst-plugins-base:1.0[abi_x86_64(-)]) required by (media-plugins/
> gst-plugins-libnice-0.1.13-r100:1.0/1.0::gentoo, ebuild scheduled for merge)
> >=media-libs/gst-plugins-
> base-1.10.5:1.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?,introspection?]
>
> (>=media-libs/gst-plugins-base-1.10.5:1.0[abi_x86_64(-),introspection])
> required by (media-libs/gst-plugins-bad-1.10.5:1.0/1.0::gentoo, ebuild
> scheduled for merge)
>
> (media-libs/gst-plugins-bad-1.10.5:1.0/1.0::gentoo, ebuild scheduled for
> merge) pulled in by
> >=media-libs/gst-plugins-bad-1.4:1.0 required by (net-libs/
> farstream-0.2.8-r1:0.2/5::gentoo, ebuild scheduled for merge)
> =
>
There's no obvious reason why portage should select
media-libs/gst-plugins-bad-1.10.5, and gst-plugins has updated cleanly
for me for months now. By I'm on ~arch and your packages are arch. Can
we re-check the obvious?
emerge --sync up to date?
emerge world done? Often times I find a partial update fails whereas all
of world succeeds, it checks all the deps and misses none
Any mixture of ~arch packages related to pidgin, farstream, gst-plugins?
Any of those packages keyworded/masked/unmasked on your system?
and finally, to see what might want gst-plugins-bad:
equery depends gst-plugins-bad
--
Alan McKinnon
alan.mckin...@gmail.com
Re: [gentoo-user] gst-plugins blocker
On Tuesday, 21 November 2017 13:36:26 GMT Alan McKinnon wrote:
> On 21/11/2017 15:03, Mick wrote:
> > I see that > media-libs/gst- plugins-base-1.12.3, so I removed various gst-plugins and
> > net-libs/farstream, emerged -1 media-libs/gst-plugins-base-1.12.3, but
> > portage continues to complain, with backtrack=99 or not.
> >
> > What is the way to overcome this?
> >
> > =
> > # emerge @preserved-rebuild -v -a
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies... done!
> > [ebuild N ] media-libs/gst-plugins-bad-1.10.5:1.0::gentoo USE="X
> > bzip2 egl introspection nls opengl orc vnc wayland -gles2 -gtk {-test}
> > -vcd" ABI_X86="(64) -32 (-x32)" 0 KiB
> > [ebuild N ] media-plugins/gst-plugins-libnice-0.1.13-r100:1.0::gentoo
> > ABI_X86="(64) -32 (-x32)" 0 KiB
> > [ebuild N ] media-libs/gst-plugins-good-1.10.5:1.0::gentoo USE="nls
> > orc" ABI_X86="(64) -32 (-x32)" 0 KiB
> > [ebuild N ] net-libs/farstream-0.2.8-r1:0.2/5::gentoo
> > USE="introspection {-test} -upnp" 0 KiB
> > [ebuild R] net-im/pidgin-2.12.0:0/2::gentoo USE="dbus gstreamer gtk
> > ncurses nls spell xscreensaver (-aqua) -debug -doc -eds -gadu -gnutls -
> > groupwise -idn -meanwhile -networkmanager -perl -pie -prediction -python
> > -sasl -silc -tcl -tk -zephyr -zeroconf" PYTHON_TARGETS="python2_7" 0 KiB
> > [blocks B ] > (" > media-libs/gst-plugins-base-1.12.3)
> >
> > Total: 5 packages (4 new, 1 reinstall), Size of downloads: 0 KiB
> > Conflict: 1 block (1 unsatisfied)
> >
> > * Error: The above package list contains packages which cannot be
> > * installed at the same time on the same system.
> >
> > (media-libs/gst-plugins-base-1.12.3:1.0/1.0::gentoo, installed) pulled
> > in by>
> > media-libs/gst-plugins-base:1.0 required by (net-im/
> >
> > pidgin-2.12.0:0/2::gentoo, ebuild scheduled for merge)
> >
> > >=media-libs/gst-plugins-base-1.4:1.0 required by (net-libs/
> >
> > farstream-0.2.8-r1:0.2/5::gentoo, ebuild scheduled for merge)
> >
> > >=media-libs/gst-plugins-
> >
> > base-1.10.5:1.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32
> > (-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s
> > 390_32(-)?,abi_s390_64(-)?]
> > (>=media-libs/gst-plugins-base-1.10.5:1.0[abi_x86_64(-)]) required by
> > (media- libs/gst-plugins-good-1.10.5:1.0/1.0::gentoo, ebuild scheduled
> > for merge)>
> > media-libs/gst-plugins-base:
> > 1.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mip
> > s_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,a
> > bi_s390_64(-)?] (media-libs/gst-plugins-base:1.0[abi_x86_64(-)]) required
> > by (media-plugins/ gst-plugins-libnice-0.1.13-r100:1.0/1.0::gentoo,
> > ebuild scheduled for merge)>
> > >=media-libs/gst-plugins-
> >
> > base-1.10.5:1.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32
> > (-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s
> > 390_32(-)?,abi_s390_64(-)?,introspection?]
> > (>=media-libs/gst-plugins-base-1.10.5:1.0[abi_x86_64(-),introspection])
> > required by (media-libs/gst-plugins-bad-1.10.5:1.0/1.0::gentoo, ebuild
> > scheduled for merge)
> >
> > (media-libs/gst-plugins-bad-1.10.5:1.0/1.0::gentoo, ebuild scheduled for
> >
> > merge) pulled in by
> >
> > >=media-libs/gst-plugins-bad-1.4:1.0 required by (net-libs/
> >
> > farstream-0.2.8-r1:0.2/5::gentoo, ebuild scheduled for merge)
> > =
>
> There's no obvious reason why portage should select
> media-libs/gst-plugins-bad-1.10.5, and gst-plugins has updated cleanly
> for me for months now. By I'm on ~arch and your packages are arch. Can
> we re-check the obvious?
>
> emerge --sync up to date?
Yes. Twice over.
> emerge world done?
Yes, but I had to exclude media-libs/gst-plugins-bad to avoid the hard blocker
and be able to emerge @world.
> Often times I find a partial update fails whereas all
> of world succeeds, it checks all the deps and misses none
> Any mixture of ~arch packages related to pidgin, farstream, gst-plugins?
> Any of those packages keyworded/masked/unmasked on your system?
All on stable versions. farstream is pulled in by pidgin.
> and finally, to see what might want gst-plugins-bad:
> equery depends gst-plugins-bad
# equery depends gst-plugins-bad
* These packages depend on gst-plugins-bad:
dev-qt/qtmultimedia-5.7.1 (gstreamer ? media-libs/gst-plugins-bad:1.0)
There are some legacy settings in /etc/portage, but I wouldn't think they
cause this block:
# grep gst -r /etc/portage/
/etc/portage/package.keywords/ffmpeg.keywords:#=media-plugins/gst-plugins-
ffmpeg-0.10.13_p201211-r5 ~amd64
/etc/portage/package.use/enlightenment:media-plugins/evas_generic_loaders
gstreamer postscript
/etc/portage/package.use/im:net-im/pidgin gtk gstreamer
/etc/portage/package.use/bluetooth:net-wireless/bluez gstreamer pcmcia
Re: [gentoo-user] gst-plugins blocker
Yesterday I experienced the same problem and ended up doing the same thing
of keywording "=media-libs/gst-plugins-bad-1.12.3".
Cheers!
On Tue, Nov 21, 2017 at 7:46 AM, Mick wrote:
> On Tuesday, 21 November 2017 13:36:26 GMT Alan McKinnon wrote:
> > On 21/11/2017 15:03, Mick wrote:
> > > I see that > > media-libs/gst- plugins-base-1.12.3, so I removed various gst-plugins
> and
> > > net-libs/farstream, emerged -1 media-libs/gst-plugins-base-1.12.3, but
> > > portage continues to complain, with backtrack=99 or not.
> > >
> > > What is the way to overcome this?
> > >
> > > =
> > > # emerge @preserved-rebuild -v -a
> > >
> > > These are the packages that would be merged, in order:
> > >
> > > Calculating dependencies... done!
> > > [ebuild N ] media-libs/gst-plugins-bad-1.10.5:1.0::gentoo USE="X
> > > bzip2 egl introspection nls opengl orc vnc wayland -gles2 -gtk {-test}
> > > -vcd" ABI_X86="(64) -32 (-x32)" 0 KiB
> > > [ebuild N ] media-plugins/gst-plugins-libnice-0.1.13-r100:1.0::
> gentoo
> > > ABI_X86="(64) -32 (-x32)" 0 KiB
> > > [ebuild N ] media-libs/gst-plugins-good-1.10.5:1.0::gentoo
> USE="nls
> > > orc" ABI_X86="(64) -32 (-x32)" 0 KiB
> > > [ebuild N ] net-libs/farstream-0.2.8-r1:0.2/5::gentoo
> > > USE="introspection {-test} -upnp" 0 KiB
> > > [ebuild R] net-im/pidgin-2.12.0:0/2::gentoo USE="dbus
> gstreamer gtk
> > > ncurses nls spell xscreensaver (-aqua) -debug -doc -eds -gadu -gnutls -
> > > groupwise -idn -meanwhile -networkmanager -perl -pie -prediction
> -python
> > > -sasl -silc -tcl -tk -zephyr -zeroconf" PYTHON_TARGETS="python2_7" 0
> KiB
> > > [blocks B ] > > (" > > media-libs/gst-plugins-base-1.12.3)
> > >
> > > Total: 5 packages (4 new, 1 reinstall), Size of downloads: 0 KiB
> > > Conflict: 1 block (1 unsatisfied)
> > >
> > > * Error: The above package list contains packages which cannot be
> > > * installed at the same time on the same system.
> > >
> > > (media-libs/gst-plugins-base-1.12.3:1.0/1.0::gentoo, installed)
> pulled
> > > in by>
> > > media-libs/gst-plugins-base:1.0 required by (net-im/
> > >
> > > pidgin-2.12.0:0/2::gentoo, ebuild scheduled for merge)
> > >
> > > >=media-libs/gst-plugins-base-1.4:1.0 required by (net-libs/
> > >
> > > farstream-0.2.8-r1:0.2/5::gentoo, ebuild scheduled for merge)
> > >
> > > >=media-libs/gst-plugins-
> > >
> > > base-1.10.5:1.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)
> ?,abi_mips_n32
> > > (-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,
> abi_ppc_64(-)?,abi_s
> > > 390_32(-)?,abi_s390_64(-)?]
> > > (>=media-libs/gst-plugins-base-1.10.5:1.0[abi_x86_64(-)]) required by
> > > (media- libs/gst-plugins-good-1.10.5:1.0/1.0::gentoo, ebuild scheduled
> > > for merge)>
> > > media-libs/gst-plugins-base:
> > > 1.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_
> n32(-)?,abi_mip
> > > s_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,
> abi_s390_32(-)?,a
> > > bi_s390_64(-)?] (media-libs/gst-plugins-base:1.0[abi_x86_64(-)])
> required
> > > by (media-plugins/ gst-plugins-libnice-0.1.13-r100:1.0/1.0::gentoo,
> > > ebuild scheduled for merge)>
> > > >=media-libs/gst-plugins-
> > >
> > > base-1.10.5:1.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)
> ?,abi_mips_n32
> > > (-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,
> abi_ppc_64(-)?,abi_s
> > > 390_32(-)?,abi_s390_64(-)?,introspection?]
> > > (>=media-libs/gst-plugins-base-1.10.5:1.0[abi_x86_64(-),
> introspection])
> > > required by (media-libs/gst-plugins-bad-1.10.5:1.0/1.0::gentoo, ebuild
> > > scheduled for merge)
> > >
> > > (media-libs/gst-plugins-bad-1.10.5:1.0/1.0::gentoo, ebuild
> scheduled for
> > >
> > > merge) pulled in by
> > >
> > > >=media-libs/gst-plugins-bad-1.4:1.0 required by (net-libs/
> > >
> > > farstream-0.2.8-r1:0.2/5::gentoo, ebuild scheduled for merge)
> > > =
> >
> > There's no obvious reason why portage should select
> > media-libs/gst-plugins-bad-1.10.5, and gst-plugins has updated cleanly
> > for me for months now. By I'm on ~arch and your packages are arch. Can
> > we re-check the obvious?
> >
> > emerge --sync up to date?
>
> Yes. Twice over.
>
>
> > emerge world done?
>
> Yes, but I had to exclude media-libs/gst-plugins-bad to avoid the hard
> blocker
> and be able to emerge @world.
>
>
> > Often times I find a partial update fails whereas all
> > of world succeeds, it checks all the deps and misses none
> > Any mixture of ~arch packages related to pidgin, farstream, gst-plugins?
> > Any of those packages keyworded/masked/unmasked on your system?
>
> All on stable versions. farstream is pulled in by pidgin.
>
>
> > and finally, to see what might want gst-plugins-bad:
> > equery depends gst-plugins-bad
>
> # equery depends gst-plugins-bad
> * These packages depend on gst-plugins-bad:
> dev-qt/qtmultimedia-5.7.1 (gstreamer ? media-libs/gst-plugins-bad:1.0)
>
>
> There are some legacy settings in /etc/por
Re: [gentoo-user] gst-plugins blocker
On Tue, Nov 21, 2017 at 8:36 AM, Alan McKinnon wrote: > On 21/11/2017 15:03, Mick wrote: >> I see that > media-libs/gst- >> plugins-base-1.12.3, so I removed various gst-plugins and net-libs/farstream, >> emerged -1 media-libs/gst-plugins-base-1.12.3, but portage continues to >> complain, with backtrack=99 or not. >> > > There's no obvious reason why portage should select > media-libs/gst-plugins-bad-1.10.5, and gst-plugins has updated cleanly > for me for months now. By I'm on ~arch and your packages are arch. Can > we re-check the obvious? > > emerge --sync up to date? The package was not correctly stabilized, and this was reported and corrected. Re-sync and the problem will go away. -- Rich
[gentoo-user] Intel ucode updates for ME issues?
I notice that an update for sys-firmware/intel-microcode just come through on ~amd64, does that address the ME issues? http://www.zdnet.com/article/intel-weve-found-severe-bugs-in-secretive-management-engine-affecting-millions/ Or will my NUC need a firmware update?
[gentoo-user] is multi-core really worth it?
Hi, rebuilding system and world with gcc-7.2.0 on a 6-core AMD CPU I have the impression that most of the ebuilds limit parallel builds to 1, 2 or 3 threads. I'm aware it is only an impression, I did not spend the night monitoring the process, but nevertheless every time I checked the load was very low. Does anyone have real-world statistics of CPU usage based on gentoo world build? raffaele
Re: [gentoo-user] is multi-core really worth it?
Hello, On Wed, Nov 22, 2017 at 12:52 AM, Raffaele Belardi wrote: > Hi, > > rebuilding system and world with gcc-7.2.0 on a 6-core AMD CPU I have the > impression that > most of the ebuilds limit parallel builds to 1, 2 or 3 threads. I'm aware it > is only an > impression, I did not spend the night monitoring the process, but > nevertheless every time > I checked the load was very low. > Assuming all of your compilation is on a RAM disk, there are two main bottlenecks that are easy to spot: network access (downloading new packages) and dependency chokepoints (packages must be compiled in a chain). Other potential chokepoints like disk access are negligible in my experience, though for one merge I did have two or three ebuilds fighting for disk IO "lock up" a system. If all dependencies have been satisfied on your system I invite you to merge a bunch of packages at once (@world?), you should notice greater parallelism. > Does anyone have real-world statistics of CPU usage based on gentoo world > build? > I've considered ways to gather these statistics off and on over the years, but it is easy to start sinking a lot of time into it. It is possible the data you want exists, but I have not found any extant solution involving portage that provides that detail of logging.* Cheers, R0b0t1 * Someone will prove me wrong in 3... 2... 1...
Re: [gentoo-user] is multi-core really worth it?
On Wed, Nov 22, 2017 at 07:52:54AM +0100, Raffaele Belardi wrote: > Hi, > > rebuilding system and world with gcc-7.2.0 on a 6-core AMD CPU I have the > impression that > most of the ebuilds limit parallel builds to 1, 2 or 3 threads. I'm aware it > is only an > impression, I did not spend the night monitoring the process, but > nevertheless every time > I checked the load was very low. multi-core is definitely worth it. Any non-trivial package (wine,glibc,gcc,llvm,qt off the top of my head) will spend a long time building many files that can be built in parallel with multiple make jobs. That being said: if you do a world rebuild you will have lots of packages that spend ~40 seconds doing their autoconf run, only to build 2-3 sources files. On an 8-core machine at work, I get good results using parallel emerge jobs (emerge -jX). For your 6-core AMD CPU (assuming it actually has 12 threads) I'd start with 'emerge -j3' and MAKEOPTS='-j12 -l16'. That should get you a nice speedup, but may require a bit more ram.
Re: [gentoo-user] is multi-core really worth it?
Hello,
On Wed, 22 Nov 2017, Raffaele Belardi wrote:
>rebuilding system and world with gcc-7.2.0 on a 6-core AMD CPU I have
>the impression that most of the ebuilds limit parallel builds to 1, 2
>or 3 threads.
Most should build with "many" cores, but some might be limited, but ...
>I'm aware it is only an impression, I did not spend the
>night monitoring the process, but nevertheless every time I checked
>the load was very low.
I guess you're mostly observing stalls because the (single-thread)
overhead of emerge, configure (etc.), which can also be IO-bound...
The actual builds probably goes so fast on your box, you hardly
notice unless they're rather big(gish).
Some numbers for comparison, and I generally build with just one
thread in the background on my 2 core "old" Athlon II X2 250:
dev-libs/boost took a good 45mins to build with one thread. Divide by
6 for your cores, divide again by about 2-3 for your newer cores and
you're in the 3:45min range for such a "biggie" as boost. Most other
stuff won't even peg your meter.
So, your emerge is mostly IO and "emerge"-threads bound. Solution:
adjust your build-threads[1], and then adjust your emerge jobs! See
'--jobs' in 'man emerge'. Can't find where to set a default in a
config-file for that ATM, but you could always alias/function/script
emerge to something else, e.g. put this in your ~/.bashrc:
eworld() {
emerge --jobs 7 [..whatever_you_use_for_world..] @world
}
or use a "proper" script in ~/bin/ for that purpose.
You might want to "tune down" your "make" threads in make.conf though,
as your'll be building 7 packages in parallell ... Well, best try it
out, and have a guess at a sweet spot between emerge-jobs and
make-jobs. I'd hazard a guess of [2-4] emerge- and [3-5] make-jobs for
your six core should be nice.
Just experiment with 'emerge -j [1..7] ... @world'...
HTH,
-dnh
PS:[lines rebroken]
# type eworld
eworld is a function
eworld ()
{
emerge --verbose --pretend --update --changed-use \
--newuse --deep --with-bdeps y "$@" @world;
beep -r 1 -l 50
}
I usually call it as: eworld -t [--verbose-conflicts].
I then "pick and build" from the result (from the bottom up, due to
"--tree"). Even with ccache, it'd be rather stupid starting a
libreoffice, firefox or icedtea build that'll take hours when I have
to leave in 10min and won't keep the box running...
[1] I think that's good practice when doing multithreaded build on
multicore: add (at least) one for IO. THREADS="$(( $N_CORES+1 ))"
You can add that in your make.conf and feed $THREADS to
MAKEOPTS="-j ${THREADS}" etc.
--
"I have always felt that violence was the last refuge of the incompetent,
and emtpy threats the final sanctuary of the terminally inept."
-- the Marquis de Carabas
