Re: [gentoo-user] OT: btrfs raid 5/6

[Richard Bradfield]

On Wed, Dec 06, 2017 at 06:35:10PM -0500, Rich Freeman wrote:

On Wed, Dec 6, 2017 at 6:28 PM, Frank Steinmetzger  wrote:


I don’t really care about performance. It’s a simple media archive powered
by the cheapest Haswell Celeron I could get (with 16 Gigs of ECC RAM though
^^). Sorry if I more or less stole the thread, but this is almost the same
topic. I could use a nudge in either direction. My workplace’s storage
comprises many 2× mirrors, but I am not a company and I am capped at four
bays.

So, Do you have any input for me before I fetch the dice?



IMO the cost savings for parity RAID trumps everything unless money
just isn't a factor.

Now, with ZFS it is frustrating because arrays are relatively
inflexible when it comes to expansion, though that applies to all
types of arrays. That is one major advantage of btrfs (and mdadm) over
zfs.  I hear they're working on that, but in general there are a lot
of things in zfs that are more static compared to btrfs.

--
Rich



When planning for ZFS pools, at least for home use, it's worth thinking
about your usage pattern, and if you'll need to expand the pool before
the lifetime of the drives rolls around.

I incorporated ZFS' expansion inflexibility into my planned
maintenance/servicing budget. I started out with 4x 2TB disks, limited
to those 4 bays as you are, but planned to replace those drives after a
period of 3-4 years.

By the time the first of my drives began to show SMART errors, the price
of a 3TB drive had dropped to what I had paid for the 2TB models, so I
bought another set and did a rolling upgrade, bringing the pool up to
6TB.

I expect I'll do the same thing late next year, I wonder if 4TB will be
the sweet spot, or if I might be able to get something larger.

--
Richard

[gentoo-user] preparing for profile switch -- major problem

[John Covici]

Hi. In preparing for the profile switch and the emerge -e world, I
have run into a serious problem with perl.  I think I saw on this list
where perl 5.26 was going to have problems -- maybe until it is
stabilized -- but if I mask it off,  I get the following:

!!! All ebuilds that could satisfy "=dev-lang/perl-5.26*" have been
masked.
!!! One of the following masked packages is required to complete
your request:
- dev-lang/perl-5.26.::gentoo (masked by: package.mask,
missing keyword)
- dev-lang/perl-5.26.1-r1::gentoo (masked by: package.mask)
- dev-lang/perl-5.26.1::gentoo (masked by: package.mask)
- dev-lang/perl-5.26.0::gentoo (masked by: package.mask)

(dependency required by "virtual/perl-Test-Harness-3.380.0::gentoo"
[ebuild])
(dependency required by "perl-core/ExtUtils-MakeMaker-7.240.0::gentoo"
[ebuild])
(dependency required by
"virtual/perl-ExtUtils-MakeMaker-7.240.0::gentoo" [ebuild])
(dependency required by "dev-perl/Class-Singleton-1.500.0::gentoo"
[ebuild])
(dependency required by "media-video/clive-2.3.0.1::gentoo" [ebuild])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])

If I don't mask it off, I get the following: (just emerging perl by
itself)


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

dev-lang/perl:0

  (dev-lang/perl-5.26.1-r1:0/5.26::gentoo, ebuild scheduled for merge)
  pulled in by
  =dev-lang/perl-5.26* required by
  (virtual/perl-ExtUtils-Manifest-1.700.0-r4:0/0::gentoo, installed)
  ^  ^
 dev-lang/perl (Argument)
(and 13 more with the same problems)

  (dev-lang/perl-5.24.3:0/5.24::gentoo, installed) pulled in by
  dev-lang/perl:0/5.24= required by
  (virtual/perl-Test-Simple-1.1.14-r3:0/0::gentoo, installed)
  
   =dev-lang/perl-5.24* required by
  (virtual/perl-Term-ANSIColor-4.40.0-r1:0/0::gentoo, installed)
 ^  ^
dev-lang/perl:0/5.24= required by
  (dev-perl/XML-Twig-3.520.0:0/0::gentoo, installed)
  
   (and 261 more with the same problems)

NOTE: Use the '--verbose-conflicts' option to display parents omitted
above

!!! The slot conflict(s) shown above involve package(s) which may need
to
!!! be rebuilt in order to solve the conflict(s). However, the
following
!!! package(s) cannot be rebuilt for the reason(s) shown:

  (virtual/perl-Test-Simple-1.1.14-r3:0/0::gentoo, installed): ebuild
  is masked or unavailable


It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.


Thanks in advance for any suggestions.


-- 
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] switch to profile 17.0 complete, completely painless

[Dale]

Andrés Becerra Sandoval wrote:
>
>
> 2017-12-06 2:18 GMT-05:00 Dale  >:
>
> Raffaele Belardi wrote:
> > One (~x86) LXDE system completed the switch with no problem, the
> other (~amd64) built all
> > except two packaged (sdlmame and torcs) which did not build with
> gcc-7.2 even before the
> > switch to 17.0.
> >
> > Gentoo devs and arch testers did a good job as usual.
> >
> > I'll do the switch on the Gnome system in the next days but up
> to now I can say that the
> > switch to 17.0 is a _lot_ less painful than switching major
> compiler version.
> >
> > raffaele
> >
> >
>
>
> I'm having trouble with these:
>
> net-libs/webkit-gtk-2.4.11-r200
> dev-qt/qtwebengine-5.9.3
> net-libs/webkit-gtk
>
> Those three, I've had to adjust the USE flags and it may or may not be
> profile switch related.  If I had to guess, it just happened to pop up
> and isn't related to the switch.  They are back in the rear
> compiling as
> I type. 
>
>
> ​Dale,
>
> How did you merge qtwebengine?
> ​
>
> -- 
>   Andrés Becerra Sandoval
>


You may have already fixed this but the way I got it to work was this:

-system-icu

I added that to my make.conf USE line and it seems to compile fine, but
with that disabled for now. 

Dale

:-)  :-)

Re: [gentoo-user] Again, emerge -e @world related questions...

[Corbin]

On 12/05/2017 02:45 PM, Michael Orlitzky wrote:
> On 12/05/2017 03:26 PM, Corbin wrote:
>> In "packages" that throw out the "CFLAGS / CXXFLAGS" values in the
>> end-users "make.conf" and substitute their own ... how will that be handled?
>>
> The GCC ebuilds all use toolchain.eclass which is incomprehensible to
> me, but it looks like the default behavior for gcc-6.x is to pass
> "--enable-default-pie" and "--enable-default-ssp" to the build process
> of GCC itself. That changes the default behavior of GCC to (as the names
> say) enable PIE and SSP by default.
>
> Consequently, if a package ignores your CFLAGS, the PIE/SSP should still
> take effect, because GCC does them by default. Only a package that adds
> its own -no-pie flag (for example) would cause problems.
>
A Master Override ... in other words.

Thank You.

Corbin

Re: [gentoo-user] OT: btrfs raid 5/6

[Rich Freeman]

On Wed, Dec 6, 2017 at 7:13 PM, Frank Steinmetzger  wrote:
> On Wed, Dec 06, 2017 at 06:35:10PM -0500, Rich Freeman wrote:
>>
>> IMO the cost savings for parity RAID trumps everything unless money
>> just isn't a factor.
>
> Cost saving compared to what? In my four-bay-scenario, mirror and raidz2
> yield the same available space (I hope so).
>

Sure, if you only have 4 drives and run raid6/z2 then it is no more
efficient than mirroring.  That said, it does provide more security
because raidz2 can tolerate the failure of any two disks, while
2xraid1 or raid10 can tolerate only half of the combinations of two
disks.

The increased efficiency of parity raid comes as you scale up.
They're equal at 4 disks.  If you had 6 disks then raid6 holds 33%
more.  If you have 8 then it holds 50% more.  That and it takes away
the chance factor when you lose two disks.  If you're really unlucky
with 4xraid1 the loss of two disks could result in the loss of 25% of
your data, while with an 8-disk raid6 the loss of two disks will never
result in the loss of any data.  (Granted, a 4xraid1 could tolerate
the loss of 4 drives if you're very lucky - the luck factor is being
eliminated and that cuts both ways.)

If I had only 4 drives I probably wouldn't use raidz2.  I might use
raid5/raidz1, or two mirrors.  With mdadm I'd probably use raid5
knowing that I can easily reshape the array if I want to expand it
further.

-- 
Rich

Re: [gentoo-user] OT: btrfs raid 5/6

[Frank Steinmetzger]

On Wed, Dec 06, 2017 at 06:35:10PM -0500, Rich Freeman wrote:
> On Wed, Dec 6, 2017 at 6:28 PM, Frank Steinmetzger  wrote:
> >
> > I don’t really care about performance. It’s a simple media archive powered
> > by the cheapest Haswell Celeron I could get (with 16 Gigs of ECC RAM though
> > ^^). Sorry if I more or less stole the thread, but this is almost the same
> > topic. I could use a nudge in either direction. My workplace’s storage
> > comprises many 2× mirrors, but I am not a company and I am capped at four
> > bays.
> >
> > So, Do you have any input for me before I fetch the dice?
> >
> 
> IMO the cost savings for parity RAID trumps everything unless money
> just isn't a factor.

Cost saving compared to what? In my four-bay-scenario, mirror and raidz2
yield the same available space (I hope so).

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

Advanced mathematics have the advantage that you can err more accurately.


signature.asc
Description: Digital signature

Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?

[Frank Steinmetzger]

On Sun, Dec 03, 2017 at 04:26:55AM +0100, tu...@posteo.de wrote:

> If the compilation will fail at a certain point (and it will fail,
> since this is a complete new thing) -- would it be possible to resume
> even some tweaks, hacks and patches (even certain recompilations)
> would be needed in between?
> 
> Can I stop a running emerge @world and resume later?
> 
> How does a restarted emerge @world recognizes packages, which are
> already compiled according to the new standard?

I “circumvent” those questions by doing:
emerge -pveD world > worldlist
emerge -1O $(cat worldlist)

If the system for whatever reason fails and I need to interrupt the merge, I
simply remove the lines from worldlist that have already been built and then
repeat the last command. Plus I can exclude some packages that don’t need a
rebuild: -bins, -docs, virtuals, most perl and tex packages and so on. This
saves a bit of time on the slower laptop.

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

This is a lousy party! I’ll leave as soon as I find my trousers.


signature.asc
Description: Digital signature

[gentoo-user] Re: is multi-core really worth it?

[Ian Zimmerman]

On 2017-12-06 16:07, Wols Lists wrote:

> The contents of /var/tmp are expected to survive a system crash, as that
> is where vi, emacs, libreoffice et al are expected to store their
> recovery logs.

The case of vi has recently been discussed extensively on oss-security
:-P

As for emacs, that's just incorrect.  By default, it puts its recovery
files in the same directory as the original file.  But of course it can
be configured differently like everything in emacs.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] Re: Puzzled with duration of chromium emerge under profile 17.0

[Mick]

On Wednesday, 6 December 2017 21:01:25 GMT Grant Edwards wrote:
> On 2017-12-06, Mick  wrote:
> > I discovered that building Chromium with gcc-6.4.0 is taking an
> > inordinately> 
> > longer time on a laptop with 1st gen i7 and 4G of RAM, e.g.:
[snip ...]

> Did the CPU throttling stuff somehow get broken when you updated to
> gcc-6.4.0?  After updating a bunch of stuff a month or two back, I
> noticed that builds suddently took 4X as long.  I finally realized
> that I had broken the CPU throttling feature and my laptop was always
> running at 400MHz and not ramping up to 2. GHz when doing
> things like compiling large packages.

Hmm ... I have not changed anything related to CPU throttling I can remember.  
Which reminds me, perhaps I should 'make clean' my kernel now that I have 
switched to gcc-6.4.0?

i7z shows turbo mode kicks in too and hyperthreading is on (attached).  Under 
turbo it jumps up to 2.8GHz.  So cpu throttling is probably not the cause of 
my problem, unless it throttles more now than it used to do before?  :-/
 
-- 
Regards,
MickCpu speed from cpuinfo 1595.00Mhz
cpuinfo might be wrong if cpufreq is enabled. To guess correctly try estimating 
via tsc
Linux's inbuilt cpu_khz code emulated now
True Frequency (without accounting Turbo) 1595 MHz
  CPU Multiplier 12x || Bus clock frequency (BCLK) 132.92 MHz

Socket [0] - [physical cores=4, logical cores=8, max online cores ever=4]
  TURBO ENABLED on 4 Cores, Hyper Threading ON
  Max Frequency without considering Turbo 1727.92 MHz (132.92 x [13])
  Max TURBO Multiplier (if Enabled) with 1/2/3/4 Cores is  21x/18x/13x/13x
  Real Current Frequency 2564.92 MHz [132.92 x 19.30] (Max of below)
Core [core-id]  :Actual Freq (Mult.)  C0%   Halt(C1)%  C3 %   C6 %  
 C7 %  Temp  VCore
Core 1 [0]:   1666.27 (12.54x)  12.55.7222.858.4
   062  0.
Core 2 [1]:   1615.74 (12.16x)  11.16.6212.869.3
   062  0.
Core 3 [2]:   1747.37 (13.15x)  14.55.9513.964.3
   062  0.
Core 4 [3]:   2564.92 (19.30x)  99.4   0   0   0
   072  0.



C0 = Processor running without halting
C1 = Processor running with halts (States >C0 are power saver modes with cores 
idling)
C3 = Cores running with PLL turned off and core cache turned off
C6, C7 = Everything in C3 + core state saved to last level cache, C7 is deeper 
than C6
  Above values in table are in percentage over the last 1 sec
[core-id] refers to core-id number in /proc/cpuinfo
'Garbage Values' message printed when garbage values are read



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

Re: [gentoo-user] Puzzled with duration of chromium emerge under profile 17.0

[Mick]

On Wednesday, 6 December 2017 20:13:50 GMT Alan McKinnon wrote:
> On 06/12/2017 21:10, Mick wrote:
> > I discovered that building Chromium with gcc-6.4.0 is taking an
> > inordinately> 
> > longer time on a laptop with 1st gen i7 and 4G of RAM, e.g.:
[snip...]

> Pure gut feel and intuition and nothing else leads me to look in two places:
> 
> You use -march=native on the i7 so I assume the same on the Core2? Those
> are rather different processors, and google is fond of optimizing deeply
> for specific cases (common to all browsers I think). You'd have to ask a
> chromium hacker but I'd say the odds are good there are serious
> optimizations for i7 that stress your compiler out muchly.

Yes, I run -march=native on both.

> Add to that your i7 is RAM-constrained so you compensate with swap,
> which is easily 50,000 times slower with sucky latency. 

Yes, it's ridiculously slow!  :-(


> When you use a
> disk as RAM, performance tanks. Well, usually it causes a cascade effect
> and stuff blows up, but if it completes it will have done so slowly.
> 
> If you at all can, shove lots more RAM in that i7. These days RAM is
> cheap and it's always by first performance tweak, then SSD.

I know that compiling in RAM would be done in a fraction of the time.  The 
thing is, this is a 8 year old laptop and I am resisting throwing good money 
after bad.  I had a quick look a few months ago and good quality memory will 
cost me around £60.  With the battery shot and the keyboard on its way out, 
I'd rather put the money towards more memory for a newer PC, sometime in the 
next year.  ;-)

-- 
Regards,
Mick

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

Re: [gentoo-user] OT: btrfs raid 5/6

[Rich Freeman]

On Wed, Dec 6, 2017 at 6:28 PM, Frank Steinmetzger  wrote:
>
> I don’t really care about performance. It’s a simple media archive powered
> by the cheapest Haswell Celeron I could get (with 16 Gigs of ECC RAM though
> ^^). Sorry if I more or less stole the thread, but this is almost the same
> topic. I could use a nudge in either direction. My workplace’s storage
> comprises many 2× mirrors, but I am not a company and I am capped at four
> bays.
>
> So, Do you have any input for me before I fetch the dice?
>

IMO the cost savings for parity RAID trumps everything unless money
just isn't a factor.

Now, with ZFS it is frustrating because arrays are relatively
inflexible when it comes to expansion, though that applies to all
types of arrays. That is one major advantage of btrfs (and mdadm) over
zfs.  I hear they're working on that, but in general there are a lot
of things in zfs that are more static compared to btrfs.

-- 
Rich

Re: [gentoo-user] OT: btrfs raid 5/6

[Frank Steinmetzger]

On Fri, Dec 01, 2017 at 12:14:12PM -0500, Rich Freeman wrote:
> On Fri, Dec 1, 2017 at 11:58 AM, Wols Lists  wrote:
> > On 27/11/17 22:30, Bill Kenworthy wrote:
> >> […]
> >> Is anyone here successfully using btrfs raid 5/6?  What is the status of
> >> scrub and self healing?  The btrfs wiki is woefully out of date :(
> >>
> > […]
> > Thing is, with raid-6 over four drives, you have a 100% certainty of
> > surviving a two-disk failure. With raid-10 you have a 33% chance of
> > losing your array.
> >
>  […]
> I tend to be a fan of parity raid in general for these reasons.  I'm
> not sure the performance gains with raid-10 are enough to warrant the
> waste of space.
> […]
> and when I finally moved it to ZFS
> […]

I am about to upgrade my Gentoo-NAS from 2× to 4×6 TB WD Red (non-pro). The
current setup is a ZFS mirror. I had been holding off the purchase for months,
all the while pondering on which RAID scheme to use. First it was raidz1 due
to space (I only have four bays), but eventually discarded it due to reduced
resilience.

Which brought me to raidz2 (any 2 drives may fail). But then I came across
that famous post by a developer on “You should always use mirrors unless you
are really really sure what you’re doing”. The main points were higher strain
on the entire array during resilvering (all drives nead to read everything
instead of just one drive) and easier maintainability of a mirror set (e.g.
faster and easier upgrade).

I don’t really care about performance. It’s a simple media archive powered
by the cheapest Haswell Celeron I could get (with 16 Gigs of ECC RAM though
^^). Sorry if I more or less stole the thread, but this is almost the same
topic. I could use a nudge in either direction. My workplace’s storage
comprises many 2× mirrors, but I am not a company and I am capped at four
bays.

So, Do you have any input for me before I fetch the dice?

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

All PCs are compatible. Some are just more compatible than others.


signature.asc
Description: Digital signature

Re: [gentoo-user] Again, emerge -e @world related questions...

[Michael Orlitzky]

On 12/05/2017 04:13 PM, Mick wrote:
> 
> I just noticed chromium shows (pic) in brackets, which I assume it means 
> forced.
> 

Yep. That information is hidden deep down in the "emerge" man page...

  --verbose [ y | n ] (-v short option)
  Tell  emerge to run in verbose mode.  Currently this flag causes
  emerge to print out GNU info errors, if any, and to show the USE
  flags  that  will  be used for each package when pretending. The
  following symbols are affixed to USE flags in order to  indicate
  their status:

  Symbol   LocationMeaning
  ──
  -prefix  not enabled (either disabled or removed)
  *suffix  transition to or from the enabled state
  %suffix  newly added or removed
  ()   circumfix   forced, masked, or removed
  {}   circumfix   state is bound to FEATURES settings

Re: [gentoo-user] switch to profile 17.0 complete, completely painless

[Neil Bothwick]

On Wed, 6 Dec 2017 18:20:54 +0200, Alan McKinnon wrote:

> I had trouble with qtwebengine. It seemed to be an issue with icu-60.*
> but I wasn't prepared to downgrade to icu-59.* just as a test (icu
> changes here tend to trigger a rebuild of half of world), and a recent
> bug on b.g.o. backed up with I was thinking.
> 
> It built fine with this in package.use:
> 
> =dev-qt/qtwebengine-5.9.3 -system-ffmpeg -system-icu
> 
> Yes, I did do it, favoured bundled libs instead of system ones. But I
> was also having similar issues with bundled vs system ffmpeg for kodi,
> and this was the easiest way to get past it and finish a 17.0 migration

Or you could have searched bgo...

https://bugs.gentoo.org/639220


-- 
Neil Bothwick

Synonym: a word you use when you can't spell the other one.


pgp4rxj2sLiHX.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: Puzzled with duration of chromium emerge under profile 17.0

[Grant Edwards]

On 2017-12-06, Mick  wrote:

> I discovered that building Chromium with gcc-6.4.0 is taking an inordinately 
> longer time on a laptop with 1st gen i7 and 4G of RAM, e.g.: 
>
>  Wed Sep 27 17:36:53 2017 >>> www-client/chromium-61.0.3163.100
>merge time: 6 hours, 40 minutes and 50 seconds.
>
>  Thu Nov  9 17:44:58 2017 >>> www-client/chromium-62.0.3202.89
>merge time: 8 hours, 12 minutes and 30 seconds.
>
> -->switch to gcc-6.4.0
>
>  Mon Dec  4 11:39:36 2017 >>> www-client/chromium-62.0.3202.89
>merge time: 20 hours, 2 minutes and 4 seconds.
>
>  Wed Dec  6 18:41:13 2017 >>> www-client/chromium-62.0.3202.94
>merge time: 22 hours, 47 minutes and 35 seconds.

Did the CPU throttling stuff somehow get broken when you updated to
gcc-6.4.0?  After updating a bunch of stuff a month or two back, I
noticed that builds suddently took 4X as long.  I finally realized
that I had broken the CPU throttling feature and my laptop was always
running at 400MHz and not ramping up to 2. GHz when doing
things like compiling large packages.

-- 
Grant Edwards   grant.b.edwardsYow! I'm using my X-RAY
  at   VISION to obtain a rare
  gmail.comglimpse of the INNER
   WORKINGS of this POTATO!!

Re: [gentoo-user] Puzzled with duration of chromium emerge under profile 17.0

[Alan McKinnon]

On 06/12/2017 21:10, Mick wrote:
> I discovered that building Chromium with gcc-6.4.0 is taking an inordinately 
> longer time on a laptop with 1st gen i7 and 4G of RAM, e.g.: 
> 
>  Wed Sep 27 17:36:53 2017 >>> www-client/chromium-61.0.3163.100
>merge time: 6 hours, 40 minutes and 50 seconds.
> 
>  Thu Nov  9 17:44:58 2017 >>> www-client/chromium-62.0.3202.89
>merge time: 8 hours, 12 minutes and 30 seconds.
> 
> -->switch to gcc-6.4.0
> 
>  Mon Dec  4 11:39:36 2017 >>> www-client/chromium-62.0.3202.89
>merge time: 20 hours, 2 minutes and 4 seconds.
> 
>  Wed Dec  6 18:41:13 2017 >>> www-client/chromium-62.0.3202.94
>merge time: 22 hours, 47 minutes and 35 seconds.
> 
> 
> but not so on another older and lesser Intel(R) Core(TM)2 Duo CPU P7550  @ 
> 2.26GHz, also with 4G RAM:
> 
>  Wed Sep 27 22:25:32 2017 >>> www-client/chromium-61.0.3163.100
>merge time: 11 hours, 46 minutes and 18 seconds.
> 
>  Thu Nov  9 22:09:59 2017 >>> www-client/chromium-62.0.3202.89
>merge time: 13 hours, 16 minutes and 41 seconds.
> 
> -->switch to gcc-6.4.0
> 
>  Sat Dec  2 21:00:59 2017 >>> www-client/chromium-62.0.3202.89
>merge time: 15 hours, 35 minutes and 50 seconds.
> 
>  Mon Dec  4 03:44:12 2017 >>> www-client/chromium-62.0.3202.94
>merge time: 15 hours, 40 minutes and 18 seconds.
> 
> 
> Any idea why this is happening?  I attach emerge info of the i7 in case you 
> can spot something which may be causing this exponential increase in emerge 
> times.  BTW, on the i7 I had to increase swap because the 4,200,960 KiB swap 
> partition was not enough to complete the compilation of version 62.0.3202.89, 
> even after I shut down all applications and exited X.  O_O
> 


Pure gut feel and intuition and nothing else leads me to look in two places:

You use -march=native on the i7 so I assume the same on the Core2? Those
are rather different processors, and google is fond of optimizing deeply
for specific cases (common to all browsers I think). You'd have to ask a
chromium hacker but I'd say the odds are good there are serious
optimizations for i7 that stress your compiler out muchly.

Add to that your i7 is RAM-constrained so you compensate with swap,
which is easily 50,000 times slower with sucky latency. When you use a
disk as RAM, performance tanks. Well, usually it causes a cascade effect
and stuff blows up, but if it completes it will have done so slowly.

If you at all can, shove lots more RAM in that i7. These days RAM is
cheap and it's always by first performance tweak, then SSD.

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] switch to profile 17.0 complete, completely painless

[Daniel Frey]

On 12/06/17 08:41, Mick wrote:

On Wednesday, 6 December 2017 15:36:19 GMT Daniel Frey wrote:

On 12/05/17 23:00, Raffaele Belardi wrote:

One (~x86) LXDE system completed the switch with no problem, the other
(~amd64) built all except two packaged (sdlmame and torcs) which did not
build with gcc-7.2 even before the switch to 17.0.

Gentoo devs and arch testers did a good job as usual.

I'll do the switch on the Gnome system in the next days but up to now I
can say that the switch to 17.0 is a _lot_ less painful than switching
major compiler version.

raffaele


I've done two machines now (6 more to go!) and it's been mostly
painless. I had the grub and cdrdao rebuild problems, solved by
upgrading to grub2 and applying a patch to lame for cdrdao. I also had
pygtk fail, but once the `emerge -e world` finished, I just had to
rebuild it and it was fine.


Dan


Are the maintainers picking up these patches to release a version bump for
packages that won't emerge with profile 17.0?



Well, I got the patch from the cdrdao bugreport. Someone sent the patch 
for lame upstream, and of course they said you should be patching 
cdrdao... so who knows.


Dan

[gentoo-user] Puzzled with duration of chromium emerge under profile 17.0

[Mick]

I discovered that building Chromium with gcc-6.4.0 is taking an inordinately 
longer time on a laptop with 1st gen i7 and 4G of RAM, e.g.: 

 Wed Sep 27 17:36:53 2017 >>> www-client/chromium-61.0.3163.100
   merge time: 6 hours, 40 minutes and 50 seconds.

 Thu Nov  9 17:44:58 2017 >>> www-client/chromium-62.0.3202.89
   merge time: 8 hours, 12 minutes and 30 seconds.

-->switch to gcc-6.4.0

 Mon Dec  4 11:39:36 2017 >>> www-client/chromium-62.0.3202.89
   merge time: 20 hours, 2 minutes and 4 seconds.

 Wed Dec  6 18:41:13 2017 >>> www-client/chromium-62.0.3202.94
   merge time: 22 hours, 47 minutes and 35 seconds.


but not so on another older and lesser Intel(R) Core(TM)2 Duo CPU P7550  @ 
2.26GHz, also with 4G RAM:

 Wed Sep 27 22:25:32 2017 >>> www-client/chromium-61.0.3163.100
   merge time: 11 hours, 46 minutes and 18 seconds.

 Thu Nov  9 22:09:59 2017 >>> www-client/chromium-62.0.3202.89
   merge time: 13 hours, 16 minutes and 41 seconds.

-->switch to gcc-6.4.0

 Sat Dec  2 21:00:59 2017 >>> www-client/chromium-62.0.3202.89
   merge time: 15 hours, 35 minutes and 50 seconds.

 Mon Dec  4 03:44:12 2017 >>> www-client/chromium-62.0.3202.94
   merge time: 15 hours, 40 minutes and 18 seconds.


Any idea why this is happening?  I attach emerge info of the i7 in case you 
can spot something which may be causing this exponential increase in emerge 
times.  BTW, on the i7 I had to increase swap because the 4,200,960 KiB swap 
partition was not enough to complete the compilation of version 62.0.3202.89, 
even after I shut down all applications and exited X.  O_O

-- 
Regards,
Mick~ $ emerge --info www-client/chromium
Portage 2.3.13 (python 3.5.4-final-0, default/linux/amd64/17.0/desktop/plasma, g
cc-6.4.0, glibc-2.25-r9, 4.12.12-gentoo x86_64)
=
 System Settings
=
System uname: Linux-4.12.12-gentoo-x86_64-Intel-R-_Core-TM-_i7_CPU_Q_720_@_1.60G
Hz-with-gentoo-2.4.1
KiB Mem: 4032296 total,   2050332 free
KiB Swap:4200960 total,   4200960 free
Timestamp of repository gentoo: Wed, 06 Dec 2017 18:15:01 +
Head commit of repository gentoo: f2378f105da3bbdc56fe40323b97dd31044b8dcc
sh bash 4.3_p48-r1
ld GNU ld (Gentoo 2.29.1 p3) 2.29.1
app-shells/bash:  4.3_p48-r1::gentoo
dev-lang/perl:5.24.3::gentoo
dev-lang/python:  2.7.14::gentoo, 3.5.4::gentoo
dev-util/cmake:   3.8.2::gentoo
dev-util/pkgconfig:   0.29.2::gentoo
sys-apps/baselayout:  2.4.1-r2::gentoo
sys-apps/openrc:  0.34.11::gentoo
sys-apps/sandbox: 2.10-r4::gentoo
sys-devel/autoconf:   2.13::gentoo, 2.69::gentoo
sys-devel/automake:   1.15.1-r1::gentoo
sys-devel/binutils:   2.29.1-r1::gentoo
sys-devel/gcc:6.4.0::gentoo
sys-devel/gcc-config: 1.8-r1::gentoo
sys-devel/libtool:2.4.6-r3::gentoo
sys-devel/make:   4.2.1::gentoo
sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers)
sys-libs/glibc:   2.25-r9::gentoo
Repositories:

gentoo
location: /usr/portage
sync-type: rsync
sync-uri: rsync://10.10.10.2/gentoo-portage
priority: -1000
sync-rsync-extra-opts: --exclude-from=/etc/portage/rsync_excludes

bar
location: /var/lib/layman/bar
masters: gentoo
priority: 50

brother-overlay
location: /var/lib/layman/brother-overlay
masters: gentoo
priority: 50

psix-overlay
location: /var/lib/layman/psix-overlay
masters: gentoo
priority: 50

local
location: /usr/local/portage
masters: gentoo
priority: 100

Installed sets: @enlightenment
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config
/usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/
fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /et
c/terminfo"
CXXFLAGS="-march=native -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--quiet-build=n"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild
-locks fail-clean fixlafiles merge-sync multilib-strict network-sandbox news par
allel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict unknow
n-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox user
sync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://10.10.10.2:1024/ http://mirror.qubenet.net/mirror/gentoo/
 rsync://rsync.mirrorservice.org/distfiles.gentoo.org/ http://ftp.snt.utwente.nl
/pub/os/linux/gentoo ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo http://www.mir
rorservice.org/sites/distfiles.gentoo.org/"
LANG="en_GB.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"

Re: [gentoo-user] Re: emerge --info

[Adam Carter]

On Wed, Dec 6, 2017 at 11:42 PM, Martin Vaeth  wrote:

> Adam Carter  wrote:
> > so why have it if you force it off?
>
> One thing is the ebuild and the other is the profile:
> It might be different in a different profile


Ok ill have a look though the profiles to see what they're doing.

Re: [gentoo-user] emerge --info

[Adam Carter]

On Thu, Dec 7, 2017 at 2:36 AM, Alan McKinnon 
wrote:

> On 06/12/2017 04:31, Adam Carter wrote:
> > Does the output reflect;
> > 1. What will be used for the next build
> > 2. What was used on the last successful build
> > 3. What was used on the last build attempt
> >
> > If its 1 or 3, then USE=custom-cflags does not work on firefox...
>
> It reflects what is currently right now in make.conf with zero
> consideration to last, future, next or previous builds.


Thanks. That's what I was trying, but failing, to say with #1,

Re: [gentoo-user] is multi-core really worth it?

[Kai Peter]

On 2017-12-06 16:34, Alan McKinnon wrote:


And just to round off a mostly pointless discussion with little real
merit, the really stupid thing about portage is why oh why are ports 
and

distfiles in /usr?
I'm really surprised that someone recognized this or may be does 
question this. Fortunately it is easy to change for the user on a per 
installation base, but not for the upstream because of the things which 
follows.


I'll tell you why, it's because that's where FreeBSD puts them, and
drobbins built Gentoo back in the day heavily borrowing from his
pleasant FreeBSD experience (he went there for 6 months recovering from
his departure from another distro, the one with the "toxic
personality"). And no-one ever bothered changing that initial decision 
-

a classic case of cargo cult
That you not aware of it doesn't indicate that it wasn't bothered. 
Perhaps people will not waste (any more) time with senseless discussions 
...


--
Sent with eQmail-1.10

Re: [gentoo-user] switch to profile 17.0 complete, completely painless

[Mick]

On Wednesday, 6 December 2017 15:36:19 GMT Daniel Frey wrote:
> On 12/05/17 23:00, Raffaele Belardi wrote:
> > One (~x86) LXDE system completed the switch with no problem, the other
> > (~amd64) built all except two packaged (sdlmame and torcs) which did not
> > build with gcc-7.2 even before the switch to 17.0.
> > 
> > Gentoo devs and arch testers did a good job as usual.
> > 
> > I'll do the switch on the Gnome system in the next days but up to now I
> > can say that the switch to 17.0 is a _lot_ less painful than switching
> > major compiler version.
> > 
> > raffaele
> 
> I've done two machines now (6 more to go!) and it's been mostly
> painless. I had the grub and cdrdao rebuild problems, solved by
> upgrading to grub2 and applying a patch to lame for cdrdao. I also had
> pygtk fail, but once the `emerge -e world` finished, I just had to
> rebuild it and it was fine.
> 
> 
> Dan

Are the maintainers picking up these patches to release a version bump for 
packages that won't emerge with profile 17.0?

-- 
Regards,
Mick

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

Re: [gentoo-user] Sandbox violations when installing a Python package

[Michael Orlitzky]

On 12/06/2017 11:09 AM, Helmut Jarausch wrote:
> 
> But then using this version of imapclient fails since it wants
> dev-python/backports-ssl (from PyPi).
> But  dev-python/backports-ssl-0.0.9  doesn't install here before a name  
> clash with dev-python/backports-1.0.
> And no, this version of backports doesn't contain the 'ssl' class
> 
> How did you solve this.

I didn't get that far. Once it installed, I came here to report my progress.


> I nothing helps, I will rename backports to old-backports and patch  
> imapclient correspondingly.

That /sounds/ like a bad idea, but I don't know enough about these
packages to say for sure. If you ask in #gentoo-python, you might
encourage someone who knows how to fix that to do so. There is an open
bug for the new version: https://bugs.gentoo.org/571310

Re: [gentoo-user] switch to profile 17.0 complete, completely painless

[Andrés Becerra Sandoval]

El dic 6, 2017 11:20 AM, "Helmut Jarausch"  escribió:

On 12/06/2017 04:38:02 PM, Andrés Becerra Sandoval wrote:

>
>  I'm having trouble with these:
>
>  net-libs/webkit-gtk-2.4.11-r200
>

this needs an addtional patch  webkit-gtk-2.4.11-icu59.patch which I've
attached

 dev-qt/qtwebengine-5.9.3
>

  This needs a tiny change, I've attached my ebuild

 net-libs/webkit-gtk
>

which version?  Version 2.18.3 installed just fine here.

Helmut



Thank you Helmut!

Re: [gentoo-user] switch to profile 17.0 complete, completely painless

[Alan McKinnon]

On 06/12/2017 17:38, Andrés Becerra Sandoval wrote:
> 
> 
> 2017-12-06 2:18 GMT-05:00 Dale  >:
> 
> Raffaele Belardi wrote:
> > One (~x86) LXDE system completed the switch with no problem, the
> other (~amd64) built all
> > except two packaged (sdlmame and torcs) which did not build with
> gcc-7.2 even before the
> > switch to 17.0.
> >
> > Gentoo devs and arch testers did a good job as usual.
> >
> > I'll do the switch on the Gnome system in the next days but up to
> now I can say that the
> > switch to 17.0 is a _lot_ less painful than switching major
> compiler version.
> >
> > raffaele
> >
> >
> 
> 
> I'm having trouble with these:
> 
> net-libs/webkit-gtk-2.4.11-r200
> dev-qt/qtwebengine-5.9.3
> net-libs/webkit-gtk
> 
> Those three, I've had to adjust the USE flags and it may or may not be
> profile switch related.  If I had to guess, it just happened to pop up
> and isn't related to the switch.  They are back in the rear compiling as
> I type. 
> 
> 
> ​Dale,
> 
> How did you merge qtwebengine?


I had trouble with qtwebengine. It seemed to be an issue with icu-60.*
but I wasn't prepared to downgrade to icu-59.* just as a test (icu
changes here tend to trigger a rebuild of half of world), and a recent
bug on b.g.o. backed up with I was thinking.

It built fine with this in package.use:

=dev-qt/qtwebengine-5.9.3 -system-ffmpeg -system-icu

Yes, I did do it, favoured bundled libs instead of system ones. But I
was also having similar issues with bundled vs system ffmpeg for kodi,
and this was the easiest way to get past it and finish a 17.0 migration


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] switch to profile 17.0 complete, completely painless

[Helmut Jarausch]

On 12/06/2017 04:38:02 PM, Andrés Becerra Sandoval wrote:


 I'm having trouble with these:

 net-libs/webkit-gtk-2.4.11-r200


this needs an addtional patch  webkit-gtk-2.4.11-icu59.patch which I've  
attached



 dev-qt/qtwebengine-5.9.3


  This needs a tiny change, I've attached my ebuild


 net-libs/webkit-gtk


which version?  Version 2.18.3 installed just fine here.

Helmut


# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

EAPI=6
PYTHON_COMPAT=( python2_7 )
inherit multiprocessing pax-utils python-any-r1 qt5-build

DESCRIPTION="Library for rendering dynamic web content in Qt5 C++ and QML 
applications"

if [[ ${QT5_BUILD_TYPE} == release ]]; then
KEYWORDS="~amd64 ~arm ~arm64 ~x86"
fi

IUSE="alsa bindist geolocation pax_kernel pulseaudio +system-ffmpeg +system-icu 
widgets"

RDEPEND="
app-arch/snappy:=
dev-libs/glib:2
dev-libs/nspr
dev-libs/nss
~dev-qt/qtcore-${PV}
~dev-qt/qtdeclarative-${PV}
~dev-qt/qtgui-${PV}
~dev-qt/qtnetwork-${PV}
~dev-qt/qtprintsupport-${PV}
~dev-qt/qtwebchannel-${PV}[qml]
dev-libs/expat
dev-libs/libevent:=
dev-libs/libxml2
dev-libs/libxslt
dev-libs/protobuf:=
media-libs/fontconfig
media-libs/freetype
media-libs/harfbuzz:=
media-libs/libpng:0=
>=media-libs/libvpx-1.5:=[svc]
media-libs/libwebp:=
media-libs/mesa
media-libs/opus
net-libs/libsrtp:0=
sys-apps/dbus
sys-apps/pciutils
sys-libs/libcap
sys-libs/zlib[minizip]
virtual/jpeg:0
virtual/libudev
x11-libs/libdrm
x11-libs/libX11
x11-libs/libXcomposite
x11-libs/libXcursor
x11-libs/libXdamage
x11-libs/libXext
x11-libs/libXfixes
x11-libs/libXi
x11-libs/libXrandr
x11-libs/libXrender
x11-libs/libXScrnSaver
x11-libs/libXtst
alsa? ( media-libs/alsa-lib )
geolocation? ( ~dev-qt/qtpositioning-${PV} )
pulseaudio? ( media-sound/pulseaudio:= )
system-ffmpeg? ( media-video/ffmpeg:0= )
system-icu? ( dev-libs/icu:= )
widgets? ( ~dev-qt/qtwidgets-${PV} )
"
DEPEND="${RDEPEND}
${PYTHON_DEPS}
>=app-arch/gzip-1.7
dev-util/gperf
dev-util/ninja
dev-util/re2c
sys-devel/bison
pax_kernel? ( sys-apps/elfix )
"

src_prepare() {
use pax_kernel && PATCHES+=( 
"${FILESDIR}/${PN}-5.9.0-paxmark-mksnapshot.patch" )
sed -i -e'/#if U_ICU_VERSION_MAJOR_NUM < 60/ s/60/60 || 
defined(TOOLKIT_QT)/' \
src/3rdparty/chromium/components/url_formatter/url_formatter.cc
# bug 620444 - ensure local headers are used
find "${S}" -type f -name "*.pr[fio]" | xargs sed -i -e 's|INCLUDEPATH 
+= |&$$QTWEBENGINE_ROOT/include |' || die

qt_use_disable_config alsa alsa src/core/config/linux.pri
qt_use_disable_config pulseaudio pulseaudio src/core/config/linux.pri

qt_use_disable_mod geolocation positioning \
mkspecs/features/configure.prf \
src/core/core_chromium.pri \
src/core/core_common.pri

qt_use_disable_mod widgets widgets src/src.pro

qt5-build_src_prepare
}

src_configure() {
export NINJA_PATH=/usr/bin/ninja
export NINJAFLAGS="${NINJAFLAGS:--j$(makeopts_jobs) 
-l$(makeopts_loadavg "${MAKEOPTS}" 0) -v}"

local myqmakeargs=(
$(usex bindist '' 'WEBENGINE_CONFIG+=use_proprietary_codecs')
$(usex system-ffmpeg 'WEBENGINE_CONFIG+=use_system_ffmpeg' '')
$(usex system-icu 'WEBENGINE_CONFIG+=use_system_icu' '')
)
qt5-build_src_configure
}

src_install() {
qt5-build_src_install

# bug 601472
if [[ ! -f ${D%/}${QT5_LIBDIR}/libQt5WebEngine.so ]]; then
die "${CATEGORY}/${PF} failed to build anything. Please report 
to https://bugs.gentoo.org/;
fi

pax-mark m "${D%/}${QT5_LIBEXECDIR}"/QtWebEngineProcess
}
diff -ruN webkitgtk-2.4.11.orig/Source/JavaScriptCore/API/JSStringRef.cpp webkitgtk-2.4.11/Source/JavaScriptCore/API/JSStringRef.cpp
--- webkitgtk-2.4.11.orig/Source/JavaScriptCore/API/JSStringRef.cpp	2016-04-10 08:48:36.0 +0200
+++ webkitgtk-2.4.11/Source/JavaScriptCore/API/JSStringRef.cpp	2017-06-11 19:26:55.263795188 +0200
@@ -37,7 +37,7 @@
 JSStringRef JSStringCreateWithCharacters(const JSChar* chars, size_t numChars)
 {
 initializeThreading();
-return OpaqueJSString::create(chars, numChars).leakRef();
+return OpaqueJSString::create(reinterpret_cast(chars), numChars).leakRef();
 }
 
 JSStringRef JSStringCreateWithUTF8CString(const char* string)
@@ -62,7 +62,7 @@
 JSStringRef JSStringCreateWithCharactersNoCopy(const JSChar* chars, size_t numChars)
 {
 initializeThreading();
-

Re: [gentoo-user] is multi-core really worth it?

[Wols Lists]

On 06/12/17 15:34, Alan McKinnon wrote:
> Those guidelines you mention about what /tmp and /var/tmp are "for" are
> probably from the FHS. On the whole, I tend to agree they are good ideas
> but the proper wording is more like this (from memory, being far too
> lazy after a day's work to actually look something up):
> 
> - contents of /tmp are not expected to survive the invocation of the
> program that created them

http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES

> - contents of /var/tmp are not expected to survive a reboot
> 
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE

> Which is different from what you said.

Except that /var/tmp is exactly the opposite of what you said :-)

 Not surprisingly, if you follow
> that through, you can run rm -rf /tmp/* in a cron every minute and
> nothing should ever break. Or, every file in /tmp can be anonymous (just
> an inode without a dentry giving it a name)

Cheers,
Wol

Re: [gentoo-user] Sandbox violations when installing a Python package

[Helmut Jarausch]

On 12/06/2017 03:32:12 PM, Michael Orlitzky wrote:

On 12/06/2017 09:08 AM, Helmut Jarausch wrote:
> Hi,
>
> I hope somebody can help me.
>
> I've written a new ebuild for  "dev-python/imapclient-1.1.0" (the
> latest version in the tree is version 0.13)...
>
> Ebuilding this packages dies of a Sandbox Violation:
>

Post the full build log and ebuild? I was able to get the new version  
to

compile and install after using "sed" to loosen the sphinx dependency,

  sed -i "s/1\.5/2.0/" setup.py || die


Hi Michael,
this 'sed' helped me to emerge imapclient-1.1.0



and after removing the two lines,

  rm imapclient/six.py || die
  epatch "${FILESDIR}"/0.12-tests.patch


Version 1.1.0 doesn't have the file imapclient/six.py nor does the  
patch apply.


But then using this version of imapclient fails since it wants
dev-python/backports-ssl (from PyPi).
But  dev-python/backports-ssl-0.0.9  doesn't install here before a name  
clash with dev-python/backports-1.0.

And no, this version of backports doesn't contain the 'ssl' class

How did you solve this.
I nothing helps, I will rename backports to old-backports and patch  
imapclient correspondingly.


Many thanks for  your help,
Helmut

Re: [gentoo-user] is multi-core really worth it?

[Wols Lists]

On 06/12/17 15:34, Alan McKinnon wrote:
> - contents of /tmp are not expected to survive the invocation of the
> program that created them
> - contents of /var/tmp are not expected to survive a reboot

That sounds completely wrong, actually.

The contents of /var/tmp are expected to survive a system crash, as that
is where vi, emacs, libreoffice et al are expected to store their
recovery logs.

Not much point putting the logs somewhere where they will be deleted by
the very occurrence they are intended to protect against ...

And yes, the rules for /tmp are "don't expect to find anything you put
there will be there a few minutes later ..." :-)

Cheers,
Wol

Re: [gentoo-user] switch to profile 17.0 complete, completely painless

[Dale]

Andrés Becerra Sandoval wrote:
>
>
> 2017-12-06 2:18 GMT-05:00 Dale  >:
>
> Raffaele Belardi wrote:
> > One (~x86) LXDE system completed the switch with no problem, the
> other (~amd64) built all
> > except two packaged (sdlmame and torcs) which did not build with
> gcc-7.2 even before the
> > switch to 17.0.
> >
> > Gentoo devs and arch testers did a good job as usual.
> >
> > I'll do the switch on the Gnome system in the next days but up
> to now I can say that the
> > switch to 17.0 is a _lot_ less painful than switching major
> compiler version.
> >
> > raffaele
> >
> >
>
>
> I'm having trouble with these:
>
> net-libs/webkit-gtk-2.4.11-r200
> dev-qt/qtwebengine-5.9.3
> net-libs/webkit-gtk
>
> Those three, I've had to adjust the USE flags and it may or may not be
> profile switch related.  If I had to guess, it just happened to pop up
> and isn't related to the switch.  They are back in the rear
> compiling as
> I type. 
>
>
> ​Dale,
>
> How did you merge qtwebengine?
> ​
>
> -- 
>   Andrés Becerra Sandoval
>


LOL.  So far, I haven't been able to get it too.  I'm starting to
disable USE flags to see if I can either get it to compile OR get rid of
the package.  I don't think the later is possible since it has a wide
range of things depending on it. 

If I get a fix, I'll post it and let you try it.  I got my hammer out. 

Dale

:-)  :-) 

Re: [gentoo-user] emerge --info

[Alan McKinnon]

On 06/12/2017 04:31, Adam Carter wrote:
> Does the output reflect;
> 1. What will be used for the next build
> 2. What was used on the last successful build
> 3. What was used on the last build attempt
> 
> If its 1 or 3, then USE=custom-cflags does not work on firefox...

It reflects what is currently right now in make.conf with zero
consideration to last, future, next or previous builds.

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] is multi-core really worth it?

[Alan McKinnon]

On 06/12/2017 15:29, Wols Lists wrote:
> On 05/12/17 21:56, Neil Bothwick wrote:
>> On Tue, 05 Dec 2017 10:09:56 +, Peter Humphrey wrote:
>>
>>> $ grep tmpfs /etc/fstab
>>> tmpfs   /var/tmp/portage  tmpfs
>>> noatime,uid=portage,gid=portage,mode=0775  0 0
>>> tmpfs   /tmp  tmpfs
>>> noatime,nosuid,nodev,noexec,mode=1777   0 0
>>
>> Or you could set PORTAGE_TMPDIR to /tmp to save the second mount.
>>
> Dunno why portage puts this stuff in /var/tmp, rather than /tmp, but do
> be aware of what the standard says ...
> 
> Stuff in /tmp should be cleared at shutdown/boot.
> 
> Stuff in /var/tmp should survive a shutdown/boot.
> 
> Of course, if, like me you've put /var/tmp/portage as tmpfs, then of
> course it won't survive a reboot, contrary to spec ... :-)

Those guidelines you mention about what /tmp and /var/tmp are "for" are
probably from the FHS. On the whole, I tend to agree they are good ideas
but the proper wording is more like this (from memory, being far too
lazy after a day's work to actually look something up):

- contents of /tmp are not expected to survive the invocation of the
program that created them
- contents of /var/tmp are not expected to survive a reboot

Which is different from what you said. Not surprisingly, if you follow
that through, you can run rm -rf /tmp/* in a cron every minute and
nothing should ever break. Or, every file in /tmp can be anonymous (just
an inode without a dentry giving it a name)

The thing about standards, is that there are so many to choose from. And
the FHS has never been a standard that anyone paid much attention to.
It's also not a spec, it's a great example of a failed standard that few
if any distros ever bothered following.

Gentoo in particular never bothered following FHS explicitly; any
overlap is mostly accidental. And that is OK as Gentoo devs are
permitted to do whatever they feel like doing. Doubly so if they can
defend their decisions on technical merit.

On the whole, /var/tmp is a better place to put build files than /tmp
just in case someone does take FHS seriously - build files are
necessarily needed after the completion of the program that created them.

And just to round off a mostly pointless discussion with little real
merit, the really stupid thing about portage is why oh why are ports and
distfiles in /usr?

I'll tell you why, it's because that's where FreeBSD puts them, and
drobbins built Gentoo back in the day heavily borrowing from his
pleasant FreeBSD experience (he went there for 6 months recovering from
his departure from another distro, the one with the "toxic
personality"). And no-one ever bothered changing that initial decision -
a classic case of cargo cult


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] switch to profile 17.0 complete, completely painless

[Andrés Becerra Sandoval]

2017-12-06 2:18 GMT-05:00 Dale :

> Raffaele Belardi wrote:
> > One (~x86) LXDE system completed the switch with no problem, the other
> (~amd64) built all
> > except two packaged (sdlmame and torcs) which did not build with gcc-7.2
> even before the
> > switch to 17.0.
> >
> > Gentoo devs and arch testers did a good job as usual.
> >
> > I'll do the switch on the Gnome system in the next days but up to now I
> can say that the
> > switch to 17.0 is a _lot_ less painful than switching major compiler
> version.
> >
> > raffaele
> >
> >
>
>
> I'm having trouble with these:
>
> net-libs/webkit-gtk-2.4.11-r200
> dev-qt/qtwebengine-5.9.3
> net-libs/webkit-gtk
>
> Those three, I've had to adjust the USE flags and it may or may not be
> profile switch related.  If I had to guess, it just happened to pop up
> and isn't related to the switch.  They are back in the rear compiling as
> I type.
>
>
​Dale,

How did you merge qtwebengine?
​

-- 
  Andrés Becerra Sandoval

Re: [gentoo-user] switch to profile 17.0 complete, completely painless

[Daniel Frey]

On 12/05/17 23:00, Raffaele Belardi wrote:

One (~x86) LXDE system completed the switch with no problem, the other (~amd64) 
built all
except two packaged (sdlmame and torcs) which did not build with gcc-7.2 even 
before the
switch to 17.0.

Gentoo devs and arch testers did a good job as usual.

I'll do the switch on the Gnome system in the next days but up to now I can say 
that the
switch to 17.0 is a _lot_ less painful than switching major compiler version.

raffaele



I've done two machines now (6 more to go!) and it's been mostly 
painless. I had the grub and cdrdao rebuild problems, solved by 
upgrading to grub2 and applying a patch to lame for cdrdao. I also had 
pygtk fail, but once the `emerge -e world` finished, I just had to 
rebuild it and it was fine.



Dan

Re: [gentoo-user] Re: Emerge does want to tell me...what?

[Peter Humphrey]

On Wednesday, 6 December 2017 10:33:54 GMT Raffaele Belardi wrote:
> Peter Humphrey wrote:
> > On Tuesday, 5 December 2017 16:49:28 GMT Raffaele Belardi wrote:
> >> Looks like your -fpic modification did not make it through.
> > 
> > Do I have my syntax wrong, then?
> > 
> > # cat /etc/portage/package.env
> > www-client/palemoon nopic
> > peak ~ # cat /etc/portage/env/nopic
> > CFLAGS="${CFLAGS} -fPIC"
> > 
> > I've tried -fPIC and -fpic, but I still get the error:
> > undefined reference to 'GetDemuxerLog()'
> > 
> > I used this as guide:
> > https://wiki.gentoo.org/wiki/Knowledge_Base:Overriding_environment_vari
> > ables_per_package
> Two suggestions, neither of which I believe will solve your problem:
> - did you rebuild completely palemoon after changing the -fpic into -fPIC?
> If you issued 'emerge' as usual and not 'make' directly in the palemoon
> build dir then the answer is yes.

It is, yes.

> - could it be that CXXFLAGS is not affected by the CFLAGS change in the
> package.env? Try specifying both in the nopic file

Indeed I had missed CXXFLAGS (duh), but after adding CXXFLAGS="${CFLAGS}" to
env/nopic the result was the same.

> Sorry, I'm out of ideas.

Don't worry - I can always revert to palemoon-bin. Thanks anyway, Raffaele.

-- 
Regards,
Peter.

Re: [gentoo-user] Sandbox violations when installing a Python package

[Michael Orlitzky]

On 12/06/2017 09:08 AM, Helmut Jarausch wrote:
> Hi,
> 
> I hope somebody can help me.
> 
> I've written a new ebuild for  "dev-python/imapclient-1.1.0" (the  
> latest version in the tree is version 0.13)...
> 
> Ebuilding this packages dies of a Sandbox Violation:
> 

Post the full build log and ebuild? I was able to get the new version to
compile and install after using "sed" to loosen the sphinx dependency,

  sed -i "s/1\.5/2.0/" setup.py || die

and after removing the two lines,

  rm imapclient/six.py || die
  epatch "${FILESDIR}"/0.12-tests.patch

Before I fixed the sphinx dependency, the "build" phase was trying to
download crap from the internet. That failed due to
FEATURES="network-sandbox", but if you're not using that FEATURE, then
it may have crashed further down the line for you.

[gentoo-user] Sandbox violations when installing a Python package

[Helmut Jarausch]

Hi,

I hope somebody can help me.

I've written a new ebuild for  "dev-python/imapclient-1.1.0" (the  
latest version in the tree is version 0.13)
I've just copied dev-python/imapclient-0.13.ebuild and remove a patch  
which is no longer needed.


Ebuilding this packages dies of a Sandbox Violation:

Compiling source in  
/var/tmp/portage/dev-python/imapclient-1.1.0/work/IMAPClient-1.1.0  
...
 * python3_6: running distutils-r1_run_phase  
distutils-r1_python_compile



snip <<<


  File "/usr/lib64/python3.6/site-packages/setuptools/sandbox.py",  
line 411, in _violation

raise SandboxViolation(operation, args, kw)
setuptools.sandbox.SandboxViolation: SandboxViolation:  
mkdir('/var/tmp/portage/dev-python/imapclient-1.1.0/work/IMAPClient-1.1.0-python3_6/lib/sphinx',  
511) {}



I have used  "FEATURES=-sandbox" and I've added  addpredict and addread  
in


python_prepare_all() {
addpredict "/var/tmp/portage/dev-python/${P}/work"
addread "/var/tmp/portage/dev-python/${P}/work"
distutils-r1_python_prepare_all
}

but it still raises a Sandbox Violation.

What can I do about this?
How can I debug this.
How to stop 'setuptools' to check for a Sandbox Violation,
particularly as /var/tmp/portage/dev-python/imapclient-1.1.0/work/...
isn't critical.

Many thanks for any hints,
Helmut

Re: [gentoo-user] is multi-core really worth it?

[Wols Lists]

On 05/12/17 21:56, Neil Bothwick wrote:
> On Tue, 05 Dec 2017 10:09:56 +, Peter Humphrey wrote:
> 
>> $ grep tmpfs /etc/fstab
>> tmpfs   /var/tmp/portage  tmpfs
>> noatime,uid=portage,gid=portage,mode=0775  0 0
>> tmpfs   /tmp  tmpfs
>> noatime,nosuid,nodev,noexec,mode=1777   0 0
> 
> Or you could set PORTAGE_TMPDIR to /tmp to save the second mount.
> 
Dunno why portage puts this stuff in /var/tmp, rather than /tmp, but do
be aware of what the standard says ...

Stuff in /tmp should be cleared at shutdown/boot.

Stuff in /var/tmp should survive a shutdown/boot.

Of course, if, like me you've put /var/tmp/portage as tmpfs, then of
course it won't survive a reboot, contrary to spec ... :-)

Cheers,
Wol

[gentoo-user] Re: emerge --info

[Martin Vaeth]

Adam Carter  wrote:
> so why have it if you force it off?

One thing is the ebuild and the other is the profile:
It might be different in a different profile.

Re: [gentoo-user] grub-0.97-r16 and profile 17.0 change

[Peter Humphrey]

On Sunday, 3 December 2017 15:12:21 GMT Mick wrote:
> On 03-12-2017 ,10:57:33, Peter Humphrey wrote:
> > On Saturday, 2 December 2017 12:30:57 GMT Mick wrote:
> > > I'm getting this error after I changed my profile as per
> > > '2017-11-30-new-17-
> > > 
> > > profiles' news item:
> > > >>> Compiling source in
> > > >>> /data/tmp_var/portage/sys-boot/grub-0.97-r16/work/
> > 
> > [...]
> > 
> > > However, sys-boot/grub-0.97-r17 installed fine once keyworded on this
> > > (mostly) stable system.  This may save time for others who come across
> > > the same problem.
> > sys-boot/grub-0.97-r17
> > It has. Thanks Mick.
> 
> Unfortunately, an older system with only 50MB /boot partition did not
> have enough space to allow sys-boot/grub-0.97-r17 to install all its
> files and fs drivers.  I ended up restoring /boot from a back up.  YMMV.

I spoke too soon, too. Sys-boot/grub-0.97-r17 compiled and installed all 
right, as a package, but when I went to install it to the MBR I got an error 
complaining of a mismatch or corruption in stage X. The wording was 
something like that, and I forget the value of X. There was no mention of 
disk space, and the boot partition is 2GB, so I think it's something else.

Installing sys-boot/grub-static-0.97-r12 instead went smoothly, so I've left 
it like that for the moment.

Does the team think I should go back to grub-0.97-r17, take proper records 
and file a bug report?

-- 
Regards,
Peter.

Re: [gentoo-user] Re: git wants a password to portage sync

[Bill Kenworthy]

On 06/12/17 06:43, Alan McKinnon wrote:
> On 06/12/2017 00:35, Ian Zimmerman wrote:
>> On 2017-12-06 05:53, Bill Kenworthy wrote:
>>
>>> No, all machines are set up as keyless ssh - git has never needed it
>>> there.  In frustration I created keys and set portage up as a keyless
>>> ssh account as well, no change.
>>
>> ssh messages are sometimes misleading.  For instance, ssh would say
>> something like "pubkey authentication failed" when in fact I prohibited
>> root logins on the server.
>>
>> I'd try connecting with bare ssh as the user in question, with maximum
>> verbosity turned on (-vvv).
>>
> 
> 
> The error messages from the ssh client are, by design, intentionally
> vague. They amount to a teeny bit more detail than just "something went
> wrong", plus the available auth methods listed in parenthesis.
> 
> This is because the sshd server avoids information leakage that
> attackers could use.
> 
> To find out why ssh does not work, start by looking at the server logs,
> then examine the client is nothing obvious stands out.
> 

Got it! Needed ssh keys for portage@remote from root@local.  Its working
but no idea why its only this machine that required it.

Thanks,
BillK

Re: [gentoo-user] Re: Emerge does want to tell me...what?

[Raffaele Belardi]

Peter Humphrey wrote:
> On Tuesday, 5 December 2017 16:49:28 GMT Raffaele Belardi wrote:
> 
>> Looks like your -fpic modification did not make it through.
> 
> Do I have my syntax wrong, then?
> 
> # cat /etc/portage/package.env
> www-client/palemoon nopic
> peak ~ # cat /etc/portage/env/nopic
> CFLAGS="${CFLAGS} -fPIC"
> 
> I've tried -fPIC and -fpic, but I still get the error:
>   undefined reference to 'GetDemuxerLog()'
> 
> I used this as guide:
>   
> https://wiki.gentoo.org/wiki/Knowledge_Base:Overriding_environment_variables_per_package
> 

Two suggestions, neither of which I believe will solve your problem:
- did you rebuild completely palemoon after changing the -fpic into -fPIC? If 
you issued
'emerge' as usual and not 'make' directly in the palemoon build dir then the 
answer is yes.
- could it be that CXXFLAGS is not affected by the CFLAGS change in the 
package.env? Try
specifying both in the nopic file

Sorry, I'm out of ideas.

raffaele

Re: [gentoo-user] Re: Emerge does want to tell me...what?

[Peter Humphrey]

On Tuesday, 5 December 2017 16:49:28 GMT Raffaele Belardi wrote:

> Looks like your -fpic modification did not make it through.

Do I have my syntax wrong, then?

# cat /etc/portage/package.env
www-client/palemoon nopic
peak ~ # cat /etc/portage/env/nopic
CFLAGS="${CFLAGS} -fPIC"

I've tried -fPIC and -fpic, but I still get the error:
undefined reference to 'GetDemuxerLog()'

I used this as guide:

https://wiki.gentoo.org/wiki/Knowledge_Base:Overriding_environment_variables_per_package

-- 
Regards,
Peter.

Re: [gentoo-user] switch to profile 17.0 complete, completely painless

[Neil Bothwick]

On Wed, 6 Dec 2017 01:18:02 -0600, Dale wrote:

> I'm having trouble with these:
> 
> net-libs/webkit-gtk-2.4.11-r200
> dev-qt/qtwebengine-5.9.3
> net-libs/webkit-gtk
> 
> Those three, I've had to adjust the USE flags and it may or may not be
> profile switch related.  If I had to guess, it just happened to pop up
> and isn't related to the switch. 

I did too, but webkit-gtk was failing a rebuild before the switch, so I
think you're right. Solutions for them can be found on bgo.


-- 
Neil Bothwick

SITCOM: Single Income, Two Children, Oppressive Mortgage


pgpuAvE89oNJ6.pgp
Description: OpenPGP digital signature