Re: [gentoo-user] Re: Emerge trouble with firefox and thunderbird ...

[Wols Lists]

On 10/03/2024 22:44, Carsten Hauck wrote:



The CPU of the machine in question is in deed an old AMD. It's good to
know the reason for that build-failures, thanks a lot.
I certainly will stick to "-clang" in my package.use.


Interesting. I'm not at all sure how old my CPU is, but at four cores it 
must be getting on a bit. Sounds like I should do the same ...


Cheers,
Wol

Re: [gentoo-user] Re: Emerge trouble with firefox and thunderbird ...

[Carsten Hauck]

On 10/03/24 at 01:50, mp666 wrote:

On Sat, 9 Mar 2024 08:04:06 +, Wols Lists wrote:


For anyone else who hits this sort of problem, I did an

USE=-clang emerge --update @world

(firefox and thunderbird were the only programs I thought this would
touch), and it worked.

There were a couple of other programs that I guess got pulled in by the
changed use, but they've upgraded which is the main thing.

Thank you very much

Cheers,
Wol


This is a known problem. It generally shows itself with older
architectures like AMD Phenom II, Bulldozer, Intel Core 2 etc.
"-march=native" in the make.conf file was the culprit, IIRC, and replacing
it with core2 or amd's equivalent option solved it. I, instead, put
"-clang" in my package.use file, for firefox. No problem with Firefox
builds since then.




The CPU of the machine in question is in deed an old AMD. It's good to
know the reason for that build-failures, thanks a lot.
I certainly will stick to "-clang" in my package.use.

Greetings,
Carsten

[gentoo-user] Re: Emerge trouble with firefox and thunderbird ...

[mp666]

On Sat, 9 Mar 2024 08:04:06 +, Wols Lists wrote:

> For anyone else who hits this sort of problem, I did an
> 
> USE=-clang emerge --update @world
> 
> (firefox and thunderbird were the only programs I thought this would
> touch), and it worked.
> 
> There were a couple of other programs that I guess got pulled in by the
> changed use, but they've upgraded which is the main thing.
> 
> Thank you very much
> 
> Cheers,
> Wol

This is a known problem. It generally shows itself with older 
architectures like AMD Phenom II, Bulldozer, Intel Core 2 etc. 
"-march=native" in the make.conf file was the culprit, IIRC, and replacing 
it with core2 or amd's equivalent option solved it. I, instead, put
"-clang" in my package.use file, for firefox. No problem with Firefox 
builds since then.

Re: [gentoo-user] Re: Emerge load again

[Peter Humphreey]

On Thursday, 30 November 2023 10:16:25 GMT Nuno Silva wrote:

> The load limit is being set only for emerge, not make, so it would only
> affect the decision to start building more packages in parallel. The
> already started ongoing builds could still take the load beyond 30, with
> more than 30 processes - there is nothing set to prevent that, or is
> there?

Yes, according to that web site I found, distcc will limit the number, and it 
does seem to do so. What puzzles me is that I can't get LO to start any other 
number of make jobs than 4.

-- 
Regards,
Peter.

Re: [gentoo-user] Re: Emerge load again

[Michael]

On Thursday, 30 November 2023 10:16:25 GMT Nuno Silva wrote:
> On 2023-11-29, Michael wrote:
> > On Monday, 27 November 2023 15:39:33 GMT Peter Humphreey wrote:
> >> Hello list,
> >> 
> >> I still can't see how portage limits the load. Today I'm emerging
> >> libreoffice, and it's spending almost the whole time working with 4 CPU
> >> threads. But:
> >> 
> >> $ grep -e '\-j' -e distcc /etc/portage/make.conf
> >> EMERGE_DEFAULT_OPTS="--jobs=18 --load-average=30 --backtrack=200 --
> >> autounmask=n --keep-going  --nospinner"
> >> FEATURES="distcc userfetch buildpkg network-sandbox parallel-install
> >> sandbox userpriv usersandbox"
> >> MAKEOPTS="-j18"
> >> 
> >> I found a suggestion to use distcc in the installation handbook, which I
> >> hadn't seen there before, so I went searching for it and found how to do
> >> it. It usually works well, in this case starting 18 packages before
> >> starting LO itself. grep -rw doesn't find '4' anywere relevant under
> >> /etc/portage/ . Other times it just doesn't help at all.
> >> 
> >> What am I missing?
> > 
> > In absence of other contributions I'll offer a theoretical explanation,
> > based on random observations on my systems.
> 
> I can't explain the 4, but one thing about this configuration (although
> it's possible this has been already discussed before, apologies if
> 
> that's the case):
> > You have specified as many as 18 packages to be emerged in parallel x up
> > to 18 make jobs each.  The result of [18 x 18 = 324] is to be limited by
> > a total load average of 30.
> 
> [...]
> 
> > Were this to occur the load limit restriction would kick in and you would
> > see only up to 30 jobs listed in top, with individual package processes
> > alternating in the top list of make threads.
> 
> The load limit is being set only for emerge, not make, so it would only
> affect the decision to start building more packages in parallel. The
> already started ongoing builds could still take the load beyond 30, with
> more than 30 processes - there is nothing set to prevent that, or is
> there?

As I understand it any tasks the emerge command is spawning, including make 
jobs, will be respectful of the '--load-average 30.0'.  When only MAKEOPTS is 
specified, then a '-l 30.0' would be needed there to apply the same load limit 
average.

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

[gentoo-user] Re: Emerge load again

[Nuno Silva]

On 2023-11-29, Michael wrote:

> On Monday, 27 November 2023 15:39:33 GMT Peter Humphreey wrote:
>> Hello list,
>> 
>> I still can't see how portage limits the load. Today I'm emerging
>> libreoffice, and it's spending almost the whole time working with 4 CPU
>> threads. But:
>> 
>> $ grep -e '\-j' -e distcc /etc/portage/make.conf
>> EMERGE_DEFAULT_OPTS="--jobs=18 --load-average=30 --backtrack=200 --
>> autounmask=n --keep-going  --nospinner"
>> FEATURES="distcc userfetch buildpkg network-sandbox parallel-install sandbox
>> userpriv usersandbox"
>> MAKEOPTS="-j18"
>> 
>> I found a suggestion to use distcc in the installation handbook, which I
>> hadn't seen there before, so I went searching for it and found how to do it.
>> It usually works well, in this case starting 18 packages before starting LO
>> itself. grep -rw doesn't find '4' anywere relevant under /etc/portage/ .
>> Other times it just doesn't help at all.
>> 
>> What am I missing?
>
> In absence of other contributions I'll offer a theoretical explanation, based 
> on random observations on my systems.

I can't explain the 4, but one thing about this configuration (although
it's possible this has been already discussed before, apologies if
that's the case):

> You have specified as many as 18 packages to be emerged in parallel x up to 
> 18 
> make jobs each.  The result of [18 x 18 = 324] is to be limited by a total 
> load average of 30.
[...]
> Were this to occur the load limit restriction would kick in and you would see 
> only up to 30 jobs listed in top, with individual package processes 
> alternating in the top list of make threads.

The load limit is being set only for emerge, not make, so it would only
affect the decision to start building more packages in parallel. The
already started ongoing builds could still take the load beyond 30, with
more than 30 processes - there is nothing set to prevent that, or is
there?

-- 
Nuno Silva

[gentoo-user] Re: emerge --sync fails with a python error

[Grant Edwards]

On 2023-05-15, Dan Johansson  wrote:
> On 15.05.23 16:41, Matt Connell wrote:
>> On Mon, 2023-05-15 at 16:24 +0200, Dan Johansson wrote:
>>> RuntimeError: OpenPGP signature not found on Manifest
>> 
>> It sounds like your sync is hitting a mirror that is currently broken.
>> 
>> Are you using a defined mirror list or letting it auto-select?
>
> As far as I can tell, portage is using "auto-select".
> in /etc/portage/make.conf I do not have GENTOO_MIRRORS set.

FWIW, I find life a lot more pleasant since I switched from rsync to
git for syncing the portage tree. It sometimes used to take 10-15
minutes to sync, or the sync would sometimes just hang and have to be
restarted several times. And I had lost count of how many times I
change my GENTOO_MIRRORS setting when the mirror I had chosen had
apparently fallen back to a dial-up connectiong via a 9600 baud modem.

Re: [gentoo-user] Re: emerge -U or emerge -N

[Dale]

Neil Bothwick wrote:
> On Tue, 11 Apr 2023 01:49:50 - (UTC), Grant Edwards wrote:
>
>>> I always do both except I use the lower case 'u'. I started using
>>> Gentoo back in 2003.  Over the years, I added/changed options to
>>> emerge until I got a good sane system that works as expected and is
>>> stable. My command is emerge -auDN world and it has worked for years.
>>>  
>> Once upon a time, a little over 20 years ago, I did some studying, and
>> I searched mailing lists postings for recommendations, and I settled
>> on
>>
>>   emerge -auvND 
> I used that for a while, except like Dale I prefer to not use -v (I like
> the quiet life) but I switched to -U (--changed-use) to lower the number
> of unnecessary rebuilds.
>
>


What gets me, I have -v in make.conf for the default options.  I
shouldn't add it to the command line but I'm so used to doing so, I type
it in anyway.  It's a habit I just can't seem to break.  :/

Dale

:-)  :-) 

Re: [gentoo-user] Re: emerge -U or emerge -N

[Neil Bothwick]

On Tue, 11 Apr 2023 01:49:50 - (UTC), Grant Edwards wrote:

> > I always do both except I use the lower case 'u'. I started using
> > Gentoo back in 2003.  Over the years, I added/changed options to
> > emerge until I got a good sane system that works as expected and is
> > stable. My command is emerge -auDN world and it has worked for years.
> >  
> 
> Once upon a time, a little over 20 years ago, I did some studying, and
> I searched mailing lists postings for recommendations, and I settled
> on
> 
>   emerge -auvND 

I used that for a while, except like Dale I prefer to not use -v (I like
the quiet life) but I switched to -U (--changed-use) to lower the number
of unnecessary rebuilds.


-- 
Neil Bothwick

Confucius say :
He who play in root, eventually kill tree!


pgpOcU12fvhNH.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: emerge -U or emerge -N

[Dale]

Grant Edwards wrote:
> On 2023-04-11, Dale  wrote:
>> the...@sys-concept.com wrote:
>>> Is it better to us emerge -U or emerge -N
>> I always do both except I use the lower case 'u'. I started using
>> Gentoo back in 2003.  Over the years, I added/changed options to emerge
>> until I got a good sane system that works as expected and is stable. My
>> command is emerge -auDN world and it has worked for years.
> Once upon a time, a little over 20 years ago, I did some studying, and
> I searched mailing lists postings for recommendations, and I settled
> on
>
>   emerge -auvND 
>
> I've been using that ever since on a handful of machines. I'd have to
> spend a few minutes reading the man page to remember the significance
> of a couple of the flags, but I note that differs only in verbosity
> from Dale's usage.
>
> --
> Grant

I need to add something.  I always forget the default options I have in
make.conf.  This is the options I put in there.

EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=500 --keep-going -v
--quiet-build=y -1 --unordered-display --jobs=6 --load-average 8"

I added with-bdeps ages ago to correct some issues.  After I had to use
it a few times to fix issues, I added it to the default.  I used to have
backtrack set to 100.  After a while 100 just didn't allow it to go deep
enough.  I tried higher settings until I reached 500.  I don't recall
ever having to increase it manually since.  The -1 keeps my world file
clean.  If I want to add something to the world file, I use the --select
y option to bypass it.  The others are pretty obvious and are more of a
personal preference or based on my CPU etc. 

I might add, it is rare that emerge can't find a path to do updates. 
Other than known bugs, it's also rare that I have problems with things
not working with software, unless it is me doing something wrong of
course.  :/

Hope this helps, someone at least. 

Dale

:-)  :-) 

[gentoo-user] Re: emerge -U or emerge -N

[Grant Edwards]

On 2023-04-11, Dale  wrote:
> the...@sys-concept.com wrote:
>> Is it better to us emerge -U or emerge -N
>
> I always do both except I use the lower case 'u'. I started using
> Gentoo back in 2003.  Over the years, I added/changed options to emerge
> until I got a good sane system that works as expected and is stable. My
> command is emerge -auDN world and it has worked for years.

Once upon a time, a little over 20 years ago, I did some studying, and
I searched mailing lists postings for recommendations, and I settled
on

  emerge -auvND 

I've been using that ever since on a handful of machines. I'd have to
spend a few minutes reading the man page to remember the significance
of a couple of the flags, but I note that differs only in verbosity
from Dale's usage.

--
Grant

Re: [gentoo-user] Re: emerge times blown out

[Adam Carter]

Thanks everyone for your suggestions. I've checked the frequencies of the
cores and they are scaling properly:
cpu MHz : 4024.653
cpu MHz : 4024.678
cpu MHz : 4024.639
cpu MHz : 4024.605
cpu MHz : 4024.643
etc

Will continue to pursue these lines of thought.

Re: [gentoo-user] Re: emerge times blown out

[Stefan Schmiedl]

Samstag, 18. Februar 2023 19:05:

 
>
>On 2023-02-18, Stefan Schmiedl  wrote:
>>
>>Samstag, 18. Februar 2023 01:49:
>>>
>>>I have three systems (all ~arch) and the emerge times have blown out on all 
>>>of them across all packages. 
>>
>>When I had something like this about two years ago, the culprit was me
>>setting the cpufreq thingie in the kernel config to powersave or whatever
>>it's called ... running emerge with 800 MHz instead of 3.2 GHz produced
>>effects similar to yours.

>
>The same thing happened to me recently. Somehow, I broke the load/temp
>based CPU clock scaling on one of my machines, and it suddenly took 4X
>as long to build things as my other machines. It was running at the
>lowest clock speed possible all the time. Unfortunately, I don't
>remember exactly what I did to fix it...


CONFIG_CPU_FREQ_GOV_PERFORMANCE
CONFIG_CPU_FREQ_GOV_POWERSAVE
CONFIG_CPU_FREQ_GOV_USERSPACE
CONFIG_CPU_FREQ_GOV_ONDEMAND
CONFIG_CPU_FREQ_GOV_CONSERVATIVE
CONFIG_CPU_FREQ_GOV_SCHEDUTIL

Back when I finally found it, all of these were set to "n" but for POWERSAVE 
which was set to "y".
I rebuilt the kernel to use ONDEMAND and things were back to normal.

s.

[gentoo-user] Re: emerge times blown out

[Grant Edwards]

On 2023-02-18, Stefan Schmiedl  wrote:
> Samstag, 18. Februar 2023 01:49:
>  
>> I have three systems (all ~arch) and the emerge times have blown out on all 
>> of them across all packages. Worst example appears to be;
>
>>     Fri Dec 23 13:11:44 2022 >>> net-libs/webkit-gtk-2.38.3-r410
>>        merge time: 37 minutes and 8 seconds.
>
>>      Fri Dec 23 13:43:08 2022 >>> net-libs/webkit-gtk-2.38.3
>>        merge time: 31 minutes and 24 seconds.
>
>>      Sat Feb  4 21:16:40 2023 >>> net-libs/webkit-gtk-2.38.4-r410
>>        merge time: 6 hours, 53 minutes and 28 seconds.
>
>>      Sun Feb  5 04:17:12 2023 >>> net-libs/webkit-gtk-2.38.4
>>        merge time: 7 hours and 32 seconds.
>
>> Is anyone else seeing this?
>
> When I had something like this about two years ago, the culprit was me
> setting the cpufreq thingie in the kernel config to powersave or whatever
> it's called ... running emerge with 800 MHz instead of 3.2 GHz produced
> effects similar to yours.

The same thing happened to me recently. Somehow, I broke the load/temp
based CPU clock scaling on one of my machines, and it suddenly took 4X
as long to build things as my other machines. It was running at the
lowest clock speed possible all the time. Unfortunately, I don't
remember exactly what I did to fix it...

--
Grant

[gentoo-user] Re: emerge 7-9% faster with python 3.11 beta 4

[Adam Carter]

> How is it compared to PyPy3?
>
> I didn’t find pypy any faster than 3.10.

[gentoo-user] Re: "emerge --jobs=1 ..." vs "MAKEOPTS=-j1 emerge ..."

[Holger Hoffstätte]

On 2020-06-21 11:53, Dr Rainer Woitok wrote:

Greetings,

is there any difference between running "emerge --jobs=1 ..."  and runn-
ing "MAKEOPTS=-j1 emerge ..."?


--jobs=1 starts one package build at a time, possibly using many parallel
processes - depending on MAKEOPTS and how the build works.

MAKEOPTS sets the number of parallel processes within one package build.

They are complementary, and you can combine them. However frequently
a series of packages have dependencies (a before b before c), so starting
multiple --jobs may not have any effect. Or it may, e.g. in the case of
rebuilds or independent packages that often only use one process to build,
e.g. perl modules or something smaller. --jobs can really make a difference
since otherwise you would suffer from portage/script/shell overhead relative
to the actual work being performed.

make offers the -l parameter that constrains the number of processes by
load, and adjusts them accordingly. As an example, with 8 cores you could
use MAKEOPTS="-j8 -l8" to enable inter-ebuild parallelism and a max. load
for one package, then start several --jobs to build independent packages
without waiting for each other.

Hope this helps.

-h

Re: [gentoo-user] Re: emerge --sync: problem refreshing keys

[Stefano Crocco]

On domenica 21 luglio 2019 13:22:55 CEST Stefano Crocco wrote:
> On domenica 21 luglio 2019 12:44:14 CEST Mick wrote:
> > On Sunday, 21 July 2019 11:17:30 BST Stefano Crocco wrote:
> > > On venerdì 19 luglio 2019 21:02:40 CEST Stefano Crocco wrote:
> > > > On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote:
> > > > > On 2019-07-18 19:42, Stefano Crocco wrote:
> > > > > > Hello to everyone,
> > > > > > since yesterday emerge --sync fails because it can't refresh keys.
> > > > > > The
> > > > > > messages I get are:
> > > > > > 
> > > > > > Syncing repository 'gentoo' into '/usr/portage'...
> > > > > > 
> > > > > >  * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
> > > > > >  * Refreshing keys via WKD ... [ !! ]
> > > > > >  * Refreshing keys from keyserver hkps://keys.gentoo.org
> > > > > >  ...OpenPGP
> > > > > >  keyring
> > > > > > 
> > > > > > refresh failed:
> > > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org
> > > > > > gpg: keyserver refresh failed: No keyserver available
> > > > > > 
> > > > > > OpenPGP keyring refresh failed:
> > > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org
> > > > > > gpg: keyserver refresh failed: No keyserver available
> > > > > 
> > > > > Perhaps something to do with this?
> > > > > 
> > > > > https://www.bleepingcomputer.com/news/security/public-certificate-po
> > > > > is
> > > > > on
> > > > > in
> > > > > g->
> > > > 
> > > > can-break-some-openpgp-implementations/
> > > > 
> > > > > Aside:
> > > > > I have already switched my personal gpg configuration to use the new
> > > > > isolated keyserver.
> > > > 
> > > > Thanks for the answer. I'd heard of this attack and read this [1]
> > > > article
> > > > on gentoo.org. From what I understand, it said that in theory there
> > > > shouldn't be problems when syncing because "The gemato tool used to
> > > > verify the Gentoo ebuild repository uses WKD by default. During normal
> > > > operation it should not be affected by this vulnerability". Reading
> > > > the
> > > > article again, I now see it also says that "In the worst case; Gentoo
> > > > repository syncs will be slow or hang" which, as you suggest, could
> > > > very
> > > > well be what's happened on my system. Unfortunately, the article
> > > > doesn't
> > > > say what to do if this happens.
> > > > 
> > > > Tomorrow I'll try investigating more.
> > > > 
> > > > Stefano
> > > > 
> > > > [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html
> > > 
> > > It seems I found out how to fix the issue. I tried comparing my
> > > /usr/share/portage/config/repos.conf with the one which comes with a
> > > current stage3 and found out mine had the line
> > > 
> > > sync-openpgp-keyserver = hkps://keys.gentoo.org
> > > 
> > > which was missing in the file from stage3. Removing it (both here and in
> > > /etc/portage/repos.conf/gentoo.conf) allowed me to sync correctly. I
> > > hope
> > > this is the correct fix. I don't remember ever writing this line, so I
> > > suppose it came with the original stage3 I built my system from or was
> > > changed by another update (an update of what, however? According to
> > > `equery
> > > b`, this file doesn't belong to any package).
> > > 
> > > I hope thing will keep working.
> > > 
> > > Stefano
> > 
> > I grepped two older installations I had immediate access to and there is
> > no
> > directive containing "openpgp" anywhere within /etc/portage/.
> > 
> > In a new-ish installation there were a number of entries in /etc/portage/
> > 
> > repos.conf/gentoo.conf, but no keyserver URI:
> >  $ grep openpgp -r /etc/portage/repos.conf/gentoo.conf
> > 
> > sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc
> > sync-openpgp-key-refresh-retry-count = 40
> > sync-openpgp-key-refresh-retry-overall-timeout = 1200
> > sync-openpgp-key-refresh-retry-delay-exp-base = 2
> > sync-openpgp-key-refresh-retry-delay-max = 60
> > sync-openpgp-key-refresh-retry-delay-mult = 4
> > 
> > Perhaps you had added a keyserver as a fall back when you were configuring
> > your system to use WKD?  I haven't implemented WKD because there was no
> > news item advising us to do so.
> 
> Maybe. I really know nothing about these issues, so I'm sure I wouldn't have
> added that line by myself. Maybe I read about them somewhere and I forgot
> about it.
> 
> Stefano

If anyone is interested, I've found out a bit more about this issue. The 
mysterious line

sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc

is the default in portage since version 2.3.69 (~arch). This means that the 
problem suddenly reappeared the first time portage got updated. By chance, I'd 
just bought a new laptop and had finished installing Gentoo on it the day 
before. I tried syncing from it... and it worked. I was getting angry: on my 
desktop and my old laptop emerge --sync didn't work; on my new laptop it did. 
Of course, the three machines were configured almost in the same way, so I 
couldn't understand what could 

Re: [gentoo-user] Re: emerge --sync: problem refreshing keys

[Stefano Crocco]

On domenica 21 luglio 2019 12:44:14 CEST Mick wrote:
> On Sunday, 21 July 2019 11:17:30 BST Stefano Crocco wrote:
> > On venerdì 19 luglio 2019 21:02:40 CEST Stefano Crocco wrote:
> > > On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote:
> > > > On 2019-07-18 19:42, Stefano Crocco wrote:
> > > > > Hello to everyone,
> > > > > since yesterday emerge --sync fails because it can't refresh keys.
> > > > > The
> > > > > messages I get are:
> > > > > 
> > > > > Syncing repository 'gentoo' into '/usr/portage'...
> > > > > 
> > > > >  * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
> > > > >  * Refreshing keys via WKD ... [ !! ]
> > > > >  * Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP
> > > > >  keyring
> > > > > 
> > > > > refresh failed:
> > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org
> > > > > gpg: keyserver refresh failed: No keyserver available
> > > > > 
> > > > > OpenPGP keyring refresh failed:
> > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org
> > > > > gpg: keyserver refresh failed: No keyserver available
> > > > 
> > > > Perhaps something to do with this?
> > > > 
> > > > https://www.bleepingcomputer.com/news/security/public-certificate-pois
> > > > on
> > > > in
> > > > g->
> > > 
> > > can-break-some-openpgp-implementations/
> > > 
> > > > Aside:
> > > > I have already switched my personal gpg configuration to use the new
> > > > isolated keyserver.
> > > 
> > > Thanks for the answer. I'd heard of this attack and read this [1]
> > > article
> > > on gentoo.org. From what I understand, it said that in theory there
> > > shouldn't be problems when syncing because "The gemato tool used to
> > > verify the Gentoo ebuild repository uses WKD by default. During normal
> > > operation it should not be affected by this vulnerability". Reading the
> > > article again, I now see it also says that "In the worst case; Gentoo
> > > repository syncs will be slow or hang" which, as you suggest, could very
> > > well be what's happened on my system. Unfortunately, the article doesn't
> > > say what to do if this happens.
> > > 
> > > Tomorrow I'll try investigating more.
> > > 
> > > Stefano
> > > 
> > > [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html
> > 
> > It seems I found out how to fix the issue. I tried comparing my
> > /usr/share/portage/config/repos.conf with the one which comes with a
> > current stage3 and found out mine had the line
> > 
> > sync-openpgp-keyserver = hkps://keys.gentoo.org
> > 
> > which was missing in the file from stage3. Removing it (both here and in
> > /etc/portage/repos.conf/gentoo.conf) allowed me to sync correctly. I hope
> > this is the correct fix. I don't remember ever writing this line, so I
> > suppose it came with the original stage3 I built my system from or was
> > changed by another update (an update of what, however? According to
> > `equery
> > b`, this file doesn't belong to any package).
> > 
> > I hope thing will keep working.
> > 
> > Stefano
> 
> I grepped two older installations I had immediate access to and there is no
> directive containing "openpgp" anywhere within /etc/portage/.
> 
> In a new-ish installation there were a number of entries in /etc/portage/
> repos.conf/gentoo.conf, but no keyserver URI:
> 
>  $ grep openpgp -r /etc/portage/repos.conf/gentoo.conf
> sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc
> sync-openpgp-key-refresh-retry-count = 40
> sync-openpgp-key-refresh-retry-overall-timeout = 1200
> sync-openpgp-key-refresh-retry-delay-exp-base = 2
> sync-openpgp-key-refresh-retry-delay-max = 60
> sync-openpgp-key-refresh-retry-delay-mult = 4
> 
> Perhaps you had added a keyserver as a fall back when you were configuring
> your system to use WKD?  I haven't implemented WKD because there was no news
> item advising us to do so.

Maybe. I really know nothing about these issues, so I'm sure I wouldn't have 
added that line by myself. Maybe I read about them somewhere and I forgot 
about it.

Stefano

Re: [gentoo-user] Re: emerge --sync: problem refreshing keys

[Mick]

On Sunday, 21 July 2019 11:17:30 BST Stefano Crocco wrote:
> On venerdì 19 luglio 2019 21:02:40 CEST Stefano Crocco wrote:
> > On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote:
> > > On 2019-07-18 19:42, Stefano Crocco wrote:
> > > > Hello to everyone,
> > > > since yesterday emerge --sync fails because it can't refresh keys. The
> > > > messages I get are:
> > > > 
> > > > Syncing repository 'gentoo' into '/usr/portage'...
> > > > 
> > > >  * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
> > > >  * Refreshing keys via WKD ... [ !! ]
> > > >  * Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP
> > > >  keyring
> > > > 
> > > > refresh failed:
> > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org
> > > > gpg: keyserver refresh failed: No keyserver available
> > > > 
> > > > OpenPGP keyring refresh failed:
> > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org
> > > > gpg: keyserver refresh failed: No keyserver available
> > > 
> > > Perhaps something to do with this?
> > > 
> > > https://www.bleepingcomputer.com/news/security/public-certificate-poison
> > > in
> > > g->
> > 
> > can-break-some-openpgp-implementations/
> > 
> > > Aside:
> > > I have already switched my personal gpg configuration to use the new
> > > isolated keyserver.
> > 
> > Thanks for the answer. I'd heard of this attack and read this [1] article
> > on gentoo.org. From what I understand, it said that in theory there
> > shouldn't be problems when syncing because "The gemato tool used to
> > verify the Gentoo ebuild repository uses WKD by default. During normal
> > operation it should not be affected by this vulnerability". Reading the
> > article again, I now see it also says that "In the worst case; Gentoo
> > repository syncs will be slow or hang" which, as you suggest, could very
> > well be what's happened on my system. Unfortunately, the article doesn't
> > say what to do if this happens.
> > 
> > Tomorrow I'll try investigating more.
> > 
> > Stefano
> > 
> > [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html
> 
> It seems I found out how to fix the issue. I tried comparing my
> /usr/share/portage/config/repos.conf with the one which comes with a current
> stage3 and found out mine had the line
> 
> sync-openpgp-keyserver = hkps://keys.gentoo.org
> 
> which was missing in the file from stage3. Removing it (both here and in
> /etc/portage/repos.conf/gentoo.conf) allowed me to sync correctly. I hope
> this is the correct fix. I don't remember ever writing this line, so I
> suppose it came with the original stage3 I built my system from or was
> changed by another update (an update of what, however? According to `equery
> b`, this file doesn't belong to any package).
> 
> I hope thing will keep working.
> 
> Stefano

I grepped two older installations I had immediate access to and there is no 
directive containing "openpgp" anywhere within /etc/portage/.

In a new-ish installation there were a number of entries in /etc/portage/
repos.conf/gentoo.conf, but no keyserver URI:

 $ grep openpgp -r /etc/portage/repos.conf/gentoo.conf 
sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc
sync-openpgp-key-refresh-retry-count = 40
sync-openpgp-key-refresh-retry-overall-timeout = 1200
sync-openpgp-key-refresh-retry-delay-exp-base = 2
sync-openpgp-key-refresh-retry-delay-max = 60
sync-openpgp-key-refresh-retry-delay-mult = 4

Perhaps you had added a keyserver as a fall back when you were configuring 
your system to use WKD?  I haven't implemented WKD because there was no news 
item advising us to do so.
-- 
Regards,

Mick

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

Re: [gentoo-user] Re: emerge --sync: problem refreshing keys

[Stefano Crocco]

On venerdì 19 luglio 2019 21:02:40 CEST Stefano Crocco wrote:
> On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote:
> > On 2019-07-18 19:42, Stefano Crocco wrote:
> > > Hello to everyone,
> > > since yesterday emerge --sync fails because it can't refresh keys. The
> > > messages I get are:
> > > 
> > > Syncing repository 'gentoo' into '/usr/portage'...
> > > 
> > >  * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
> > >  * Refreshing keys via WKD ... [ !! ]
> > >  * Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP
> > >  keyring
> > > 
> > > refresh failed:
> > > gpg: refreshing 4 keys from hkps://keys.gentoo.org
> > > gpg: keyserver refresh failed: No keyserver available
> > > 
> > > OpenPGP keyring refresh failed:
> > > gpg: refreshing 4 keys from hkps://keys.gentoo.org
> > > gpg: keyserver refresh failed: No keyserver available
> > 
> > Perhaps something to do with this?
> > 
> > https://www.bleepingcomputer.com/news/security/public-certificate-poisonin
> > g->
> can-break-some-openpgp-implementations/
> 
> > Aside:
> > I have already switched my personal gpg configuration to use the new
> > isolated keyserver.
> 
> Thanks for the answer. I'd heard of this attack and read this [1] article on
> gentoo.org. From what I understand, it said that in theory there shouldn't
> be problems when syncing because "The gemato tool used to verify the Gentoo
> ebuild repository uses WKD by default. During normal operation it should
> not be affected by this vulnerability". Reading the article again, I now
> see it also says that "In the worst case; Gentoo repository syncs will be
> slow or hang" which, as you suggest, could very well be what's happened on
> my system. Unfortunately, the article doesn't say what to do if this
> happens.
> 
> Tomorrow I'll try investigating more.
> 
> Stefano
> 
> [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html

It seems I found out how to fix the issue. I tried comparing my
/usr/share/portage/config/repos.conf with the one which comes with a current 
stage3 and found out mine had the line

sync-openpgp-keyserver = hkps://keys.gentoo.org

which was missing in the file from stage3. Removing it (both here and in
/etc/portage/repos.conf/gentoo.conf) allowed me to sync correctly. I hope this 
is the correct fix. I don't remember ever writing this line, so I suppose it 
came with the original stage3 I built my system from or was changed by another 
update (an update of what, however? According to `equery b`, this file doesn't 
belong to any package).

I hope thing will keep working.

Stefano

Re: [gentoo-user] Re: emerge --sync: problem refreshing keys

[Stefano Crocco]

On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote:
> On 2019-07-18 19:42, Stefano Crocco wrote:
> > Hello to everyone,
> > since yesterday emerge --sync fails because it can't refresh keys. The
> > messages I get are:
> > 
> > Syncing repository 'gentoo' into '/usr/portage'...
> > 
> >  * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
> >  * Refreshing keys via WKD ... [ !! ]
> >  * Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP
> >  keyring
> > 
> > refresh failed:
> > gpg: refreshing 4 keys from hkps://keys.gentoo.org
> > gpg: keyserver refresh failed: No keyserver available
> > 
> > OpenPGP keyring refresh failed:
> > gpg: refreshing 4 keys from hkps://keys.gentoo.org
> > gpg: keyserver refresh failed: No keyserver available
> 
> Perhaps something to do with this?
> 
> https://www.bleepingcomputer.com/news/security/public-certificate-poisoning-> 
can-break-some-openpgp-implementations/
> 
> Aside:
> I have already switched my personal gpg configuration to use the new
> isolated keyserver.

Thanks for the answer. I'd heard of this attack and read this [1] article on 
gentoo.org. From what I understand, it said that in theory there shouldn't be 
problems when syncing because "The gemato tool used to verify the Gentoo 
ebuild repository uses WKD by default. During normal operation it should not 
be affected by this vulnerability". Reading the article again, I now see it 
also says that "In the worst case; Gentoo repository syncs will be slow or 
hang" which, as you suggest, could very well be what's happened on my system. 
Unfortunately, the article doesn't say what to do if this happens. 

Tomorrow I'll try investigating more.

Stefano

[1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html

[gentoo-user] Re: emerge --sync: problem refreshing keys

[Ian Zimmerman]

On 2019-07-18 19:42, Stefano Crocco wrote:

> Hello to everyone,
> since yesterday emerge --sync fails because it can't refresh keys. The 
> messages I get are:
> 
> Syncing repository 'gentoo' into '/usr/portage'...
>  * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
>  * Refreshing keys via WKD ... [ !! ]
>  * Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP keyring 
> refresh failed:
> gpg: refreshing 4 keys from hkps://keys.gentoo.org
> gpg: keyserver refresh failed: No keyserver available
> 
> OpenPGP keyring refresh failed:
> gpg: refreshing 4 keys from hkps://keys.gentoo.org
> gpg: keyserver refresh failed: No keyserver available

Perhaps something to do with this?

https://www.bleepingcomputer.com/news/security/public-certificate-poisoning-can-break-some-openpgp-implementations/

Aside:
I have already switched my personal gpg configuration to use the new
isolated keyserver.

-- 
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 and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: : Re: [gentoo-user] Re: Emerge --sync source

[Mick]

On Thursday, 7 March 2019 17:19:42 GMT Peter Humphrey wrote:
> Mick  wrote :
> > I can't recall the OP mentioning corrupt data, which is
> > usually the first thing observed with faulty memory.
> 
> I did, actually, last Friday. 

Oops!  My mistake.


> Numbers of files in the portage tree suddenly
> changed owner (or group), and when I fixed that git complained that my
> numerous local changes would be lost and refused to sync. Of course I
> hadn't made any local changes.

OK, first port of call in these cases is a memory test.  If errors are 
reported then reseat the RAM modules.  If the errors persist you're in the 
market for replacement modules.

If no memory errors are reported it may be RAM is not to blame and other 
causes should be investigated next.


> I've just ordered a new SSD; let's see how that goes. It's twice the size of
> the current one, so when it wears itself out I can move all the partitions
> to a new part of the disk and get a second life out of it.
> 
> Thanks all for helpful contributions.

Did you run memtest86 and if yes, what did it report?
-- 
Regards,
Mick

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

Re:: Re: [gentoo-user] Re: Emerge --sync source

[Peter Humphrey]

Mick  wrote :

> I can't recall the OP mentioning corrupt data, which is
> usually the first thing observed with faulty memory.

I did, actually, last Friday. Numbers of files in the portage tree suddenly 
changed owner (or group), and when I fixed that git complained that my numerous 
local changes would be lost and refused to sync. Of course I hadn't made any 
local changes.

I've just ordered a new SSD; let's see how that goes. It's twice the size of 
the current one, so when it wears itself out I can move all the partitions to a 
new part of the disk and get a second life out of it.

Thanks all for helpful contributions.

-- 
Regards,
Peter.

Re:: [gentoo-user] Re: Emerge --sync source

[Peter Humphrey]

Grant Edwards  wrote :

> Perhaps it's already been mentioned, but failing RAM can cause all
> sorts failures that might appear to be failing disks, failing network
> cards, failing video cards whatever.  I'd run memtest86 for at least
> 12 hours just to make sure...

Good idea. I'll try that.

-- 
Regards,
Peter.

Re: [gentoo-user] Re: Emerge --sync source

[Mick]

On Thursday, 7 March 2019 14:45:31 GMT Rich Freeman wrote:
> On Thu, Mar 7, 2019 at 9:29 AM Grant Edwards  
wrote:
> > On 2019-03-07, Mick  wrote:
> > > I can think of 3 things, but more learned M/L contributors may add to
> > > these:
> > > 
> > > 1. The SATA connection has come loose.  With time and movement it can
> > > come
> > > (slightly) adrift.  Pushing it back in fully fixes this problem - also
> > > see No. 2 below.
> > > 
> > > 2. The physical connector's contacts are beginning to oxidise.  Reseat
> > > the
> > > SATA cable connectors both on the drive and any ribbons on the MoBo. 
> > > This
> > > usualy cleans any oxidisation.
> > > 
> > > 3. The AHCI driver is deploying energy saving measures (aka. Aggressive
> > > Link> > 
> > > Power Management - ALPM).  Check the output of:
> > >  cat /sys/class/scsi_host/host*/link_power_management_policy
> > > 
> > > If it doesn't say 'max_performance' you'll need to revisit your BIOS
> > > settings and also PCIEASPM settings in the kernel.
> > > 
> > > 4. Finally, there is a chance the PSU is playing up.
> > 
> > Perhaps it's already been mentioned, but failing RAM can cause all
> > sorts failures that might appear to be failing disks, failing network
> > cards, failing video cards whatever.  I'd run memtest86 for at least
> > 12 hours just to make sure...
> 
> Failing RAM or failing power certainly can cause all manner of
> filesystem and other corruption.  I've seen it firsthand and cleaning
> up from it is a total mess (usually best to restore from backup).  I
> would definitely start with a memory test - if the motherboard is good
> then you can work outwards from there.
> 
> From what I've heard SSDs can have bizarre failure modes since they
> interpose a logical layer between the physical storage media and the
> rest of the system.  They're doing wear-leveling and so on behind the
> scenes, which means that if something goes wrong all kinds of bizarre
> problems can occur.
> 
> I've also experienced a spinning hard drive exhibit lots of data
> corruption issues due to a faulty SATA interface (not sure where in
> the interface it - chipset, port, or cable).  ZFS saved me there with
> detection and resolution of errors, and when I moved the drive to a
> different HBA it worked fine after a scrub.  I'd never seen anything
> like it before but it really made me appreciate ZFS (btrfs should have
> also worked) - I don't think mdadm would have had any way to resolve
> these errors easily, though maybe if I used a hex editor to figure out
> which drive was the bad one I might have been able to move it, wipe
> it, then re-add it to the mirror pair and let it rebuild.  With ZFS I
> just got an email complaining about errors from zed and it just kept
> beating back the hordes until I fixed the connection.  I forget if it
> dropped the drive or not - I didn't have any spares but if I did I
> suspect it would have swapped it in after enough problems.

Good points raised re. faulty memory.  Oxidisation can also occur on RAM 
modules' contacts and reseating them works well.  However, I can't recall the 
OP mentioning corrupt data, which is usually the first thing observed with 
faulty memory.

-- 
Regards,
Mick

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

Re: [gentoo-user] Re: Emerge --sync source

[Rich Freeman]

On Thu, Mar 7, 2019 at 9:29 AM Grant Edwards  wrote:
>
> On 2019-03-07, Mick  wrote:
>
> > I can think of 3 things, but more learned M/L contributors may add to these:
> >
> > 1. The SATA connection has come loose.  With time and movement it can come
> > (slightly) adrift.  Pushing it back in fully fixes this problem - also see 
> > No.
> > 2 below.
> >
> > 2. The physical connector's contacts are beginning to oxidise.  Reseat the
> > SATA cable connectors both on the drive and any ribbons on the MoBo.  This
> > usualy cleans any oxidisation.
> >
> > 3. The AHCI driver is deploying energy saving measures (aka. Aggressive Link
> > Power Management - ALPM).  Check the output of:
> >
> >  cat /sys/class/scsi_host/host*/link_power_management_policy
> >
> > If it doesn't say 'max_performance' you'll need to revisit your BIOS 
> > settings
> > and also PCIEASPM settings in the kernel.
> >
> > 4. Finally, there is a chance the PSU is playing up.
>
> Perhaps it's already been mentioned, but failing RAM can cause all
> sorts failures that might appear to be failing disks, failing network
> cards, failing video cards whatever.  I'd run memtest86 for at least
> 12 hours just to make sure...
>

Failing RAM or failing power certainly can cause all manner of
filesystem and other corruption.  I've seen it firsthand and cleaning
up from it is a total mess (usually best to restore from backup).  I
would definitely start with a memory test - if the motherboard is good
then you can work outwards from there.

>From what I've heard SSDs can have bizarre failure modes since they
interpose a logical layer between the physical storage media and the
rest of the system.  They're doing wear-leveling and so on behind the
scenes, which means that if something goes wrong all kinds of bizarre
problems can occur.

I've also experienced a spinning hard drive exhibit lots of data
corruption issues due to a faulty SATA interface (not sure where in
the interface it - chipset, port, or cable).  ZFS saved me there with
detection and resolution of errors, and when I moved the drive to a
different HBA it worked fine after a scrub.  I'd never seen anything
like it before but it really made me appreciate ZFS (btrfs should have
also worked) - I don't think mdadm would have had any way to resolve
these errors easily, though maybe if I used a hex editor to figure out
which drive was the bad one I might have been able to move it, wipe
it, then re-add it to the mirror pair and let it rebuild.  With ZFS I
just got an email complaining about errors from zed and it just kept
beating back the hordes until I fixed the connection.  I forget if it
dropped the drive or not - I didn't have any spares but if I did I
suspect it would have swapped it in after enough problems.

-- 
Rich

[gentoo-user] Re: Emerge --sync source

[Grant Edwards]

On 2019-03-07, Mick  wrote:

> I can think of 3 things, but more learned M/L contributors may add to these:
>
> 1. The SATA connection has come loose.  With time and movement it can come 
> (slightly) adrift.  Pushing it back in fully fixes this problem - also see No.
> 2 below.
>
> 2. The physical connector's contacts are beginning to oxidise.  Reseat the 
> SATA cable connectors both on the drive and any ribbons on the MoBo.  This 
> usualy cleans any oxidisation.
>
> 3. The AHCI driver is deploying energy saving measures (aka. Aggressive Link 
> Power Management - ALPM).  Check the output of:
>
>  cat /sys/class/scsi_host/host*/link_power_management_policy
>
> If it doesn't say 'max_performance' you'll need to revisit your BIOS settings 
> and also PCIEASPM settings in the kernel.
>
> 4. Finally, there is a chance the PSU is playing up.

Perhaps it's already been mentioned, but failing RAM can cause all
sorts failures that might appear to be failing disks, failing network
cards, failing video cards whatever.  I'd run memtest86 for at least
12 hours just to make sure...

-- 
Grant Edwards   grant.b.edwardsYow! Well, O.K.
  at   I'll compromise with my
  gmail.comprinciples because of
   EXISTENTIAL DESPAIR!

Re: [gentoo-user] Re: Emerge and binary packages

[Daniel Frey]

On 07/01/18 20:55, Ian Zimmerman wrote:
> 
> I ought to disclose that the server is Debian.  But the distcc versions
> on both sides were the same, and I hand-compiled a matching gcc version
> on the server.
> 
> One thing I very much dislike about distcc is that there seems to be no
> good way of using a full path to the compiler on the server that's
> different from the one on the client.
> 

I think that's probably the cause of the problem you've been having. I'm
no distcc expert by any means but you need to have binutils/libtool/gcc
identical across all machines, and in the case of different distros it
means hand compiling these on every machine, not just one - distros tend
to include their own fixes.

I found this article:

http://rostedt.homelinux.com/distcc/

which details some of these problems, but in that example they were also
compiling x32 and x64.

I've never had a problem with distcc in my all-Gentoo environment, other
than some random packages that don't like distcc.

I was actually reading about pump mode and considering trying that on my
Celerons.

Dan

[gentoo-user] Re: Emerge and binary packages

[Ian Zimmerman]

On 2018-07-01 11:57, Daniel Frey wrote:

> > Do you mind sharing your distcc setup?  I could not get it to work in
> > the way described in the wiki.

> What part were you having problems with?

I configured it to compile everything remotely (to just 1 server)
because it would be deterministic and so easier to test.  But the server
refused to compile anything at all; it complained about not being able
to obtain some lock.

I ought to disclose that the server is Debian.  But the distcc versions
on both sides were the same, and I hand-compiled a matching gcc version
on the server.

One thing I very much dislike about distcc is that there seems to be no
good way of using a full path to the compiler on the server that's
different from the one on the client.

-- 
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 and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] Re: Emerge and binary packages

[Daniel Frey]

On 07/01/18 08:51, Ian Zimmerman wrote:
> On 2018-06-30 10:50, Daniel Frey wrote:
> 
>> For many, many years I've been using binpkg to help ease the compile
>> pain on my Intel NUC Celeron-based frontends. I use distcc on one to
>> compile all my packages and export /usr/portage/packages via nfs.
> 
> Do you mind sharing your distcc setup?  I could not get it to work in
> the way described in the wiki.
> 

Sure, but what part? I don't cross-compile... all processors are
x86-based and I don't offload everything to the distcc farm. The local
Celeron chips take part in the compile process.

I offload to two machines that have quad cores and above.

What part were you having problems with?

Dan

[gentoo-user] Re: Emerge and binary packages

[Ian Zimmerman]

On 2018-06-30 10:50, Daniel Frey wrote:

> For many, many years I've been using binpkg to help ease the compile
> pain on my Intel NUC Celeron-based frontends. I use distcc on one to
> compile all my packages and export /usr/portage/packages via nfs.

Do you mind sharing your distcc setup?  I could not get it to work in
the way described in the wiki.

-- 
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 and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

[gentoo-user] Re: emerge colors and light background

[Martin Vaeth]

James Cloos  wrote:
> For eix, I have this in a file in /etc/eixrc/:
>
> BG0=none
> BG1=none
> BG2=none
> BG3=none

If you only use colorscheme 3 you need only BG3=none

> COLORSCHEME0=3
> COLORSCHEME1=3

The former (...0=3) should have no effect at all if your TERM
is recognized by eix as 256-color capable.
The latter (...1=3) should have no effect if you really have

> COLORFGBG='0;15'

in your environment: Then automatically the scheme
for white background should be chosen (from the
default value COLORSCHEME1="1 3").

> That is not as good as eix did before the current 256-color schemes were
> added

Really? With ...=0 (instead of ...=3) you get the "old" colors.
Is this really better readable even on white bg?
An attempt to "adapt" this for white bg is ...=2 (instead of ...=3):
That uses from the 8/16 system colors only those which are presumably
readable on white bg.

BTW, if somebody wants to invest time to generate a better color scheme
for 256 colors and white background for eix, I invite you to submit patches.
The requirements for acceptence of a new/alternative 256 color scheme are

1. none of the 8/16 system colors are used (because their default
values depend on the terminal and its customization and are thus
not "fixed")

2. of course readability on white background

3. differently marked things must look different _optically_ on
white background.

4. (technical detail: Use %{BG3} for the background).

2 and 3 together reduce the "apparently available" 240 colors
to a surprisingly small number. Try "eix --256d" to get an idea,
noting that not only some colors printed close to each other are
optically almost undistinguishable (the cube has 3 dimensions...)

If somebody wants to invest the time and needs just technical help,
drop me a pm or - perhaps better so that other possible contributors
can read, too - open a bug for eix on github.

Re: [gentoo-user] Re: emerge colors and light background

[Wols Lists]

On 19/04/18 16:28, John Blinka wrote:
> My sympathies to the OP.  I fought against dark terminal backgrounds
> for years (paper is white and ink is black, right?), tweaked all the
> colors through every mechanism I knew of, and never did arrive at a
> satisfactory result. 

Paper is reflective, and ink absorbs light - the opposite of a screen,
where the background is dark and the text emits light.

You do know green is a primary colour, right?

I'm not saying you're wrong to want a light background and dark text,
but there are good reasons for why a screen defaults to the opposite of
paper. (And defaults don't work for everybody :-)

Cheers,
Wol

(The three *subtractive* primaries are the well-known red, yellow and
blue. The three *additive* primaries are red, *green* and blue. Probably
(one of) the reasons why old terminals were "green screen".)

[gentoo-user] Re: emerge colors and light background

[Ian Zimmerman]

On 2018-04-19 20:57, Grant Edwards wrote:

> > It depends on your terminal app.  I use (u)rxvt and I remap the
> > colors for it globally.  Here are the settings (from .Xresources):
> >
> > *.beNiceToColormap: false
> > Rxvt.background: seashell
> > Rxvt.color10: green4
> > Rxvt.color11: orange2
> > Rxvt.color14: cyan4
> > Rxvt.color2: green3
> > Rxvt.color3: orange
> > Rxvt.color6: cyan3
> > Rxvt.foreground: Gray40
> 
> Doesn't that mess up the colors for other applications?

Of course it does, and that's the idea.  Otherwise I'd have the same
problem with these other applications!

> Or do you use the custom urxvt settings just for emerge et alia?

If you really needed that, it can be done with the urxvt -name option
which controls which Xresources entries apply.  I mentioned it the other
say over on the openbox list when someone asked for a way to change
terminal windows' icons.

-- 
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 and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

[gentoo-user] Re: emerge colors and light background

[Grant Edwards]

On 2018-04-19, Ian Zimmerman  wrote:
> On 2018-04-19 08:16, Klaus Ethgen wrote:

>> I use light background and many colors of emerge and other tools are
>> simple unreadable (like light green). I searched how to adapt them to
>> my background but did not success. I already know about color.map but
>> this just allows to tune some colors and not all (at least the ones
>> that are documented in the man page).
>
> It depends on your terminal app.  I use (u)rxvt and I remap the colors
> for it globally.  Here are the settings (from .Xresources):
>
> *.beNiceToColormap: false
> Rxvt.background: seashell
> Rxvt.color10: green4
> Rxvt.color11: orange2
> Rxvt.color14: cyan4
> Rxvt.color2: green3
> Rxvt.color3: orange
> Rxvt.color6: cyan3
> Rxvt.foreground: Gray40

Doesn't that mess up the colors for other applications?

Or do you use the custom urxvt settings just for emerge et alia?

-- 
Grant Edwards   grant.b.edwardsYow! Are we laid back yet?
  at   
  gmail.com

Re: [gentoo-user] Re: emerge colors and light background

[Daniel Frey]

On 04/19/18 07:38, Grant Edwards wrote:
> On 2018-04-19, Neil Bothwick  wrote:
>> On Thu, 19 Apr 2018 08:16:30 +0100, Klaus Ethgen wrote:
>>
>>> I use light background and many colors of emerge and other tools are
>>> simple unreadable [...]
> 
>> I use a light background in my terminal and use color.map to deal with
>> it. You can replace specific colours in color.map as well as changing
>> colours for functions, such as:
>>
>> green = purple
>> yellow=brown
> 
> Hmm. I never could get that to work acceptably, but maybe I should try
> again. Does anybody have a color.map they'd care to share for
> terminals with white backgrounds?
> 

My /etc/portage/color.map simply has:

green = purple
yellow = darkred
darkyellow = turquoise

I just did a `emerge -ep world` and I can read all of the output.

It's really only the lighter colours you need to worry about.

I only have the one machine I have a white background on, and now I
can't even remember why I set it that way.

Dan

[gentoo-user] Re: emerge colors and light background

[Ian Zimmerman]

On 2018-04-19 08:16, Klaus Ethgen wrote:

> I recently start with gentoo due to frustration of the rapidly
> degrading quality of debian.

Hello, good to meet you again ;-)

> Currently I have pretty good feelings about gentoo but there is one
> thing that is pretty annoying.
> 
> I use light background and many colors of emerge and other tools are
> simple unreadable (like light green). I searched how to adapt them to
> my background but did not success. I already know about color.map but
> this just allows to tune some colors and not all (at least the ones
> that are documented in the man page).

It depends on your terminal app.  I use (u)rxvt and I remap the colors
for it globally.  Here are the settings (from .Xresources):

*.beNiceToColormap: false
Rxvt.background: seashell
Rxvt.color10: green4
Rxvt.color11: orange2
Rxvt.color14: cyan4
Rxvt.color2: green3
Rxvt.color3: orange
Rxvt.color6: cyan3
Rxvt.foreground: Gray40

-- 
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 and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] Re: emerge colors and light background

[R0b0t1]

On Thu, Apr 19, 2018 at 9:36 AM, Grant Edwards
 wrote:
> On 2018-04-19, Klaus Ethgen  wrote:
>
>> I use light background and many colors of emerge and other tools are
>> simple unreadable (like light green).
>
> Yep, it's awful.  People have been complaining about it for years and
> years.
>
>> I searched how to adapt them to my background but did not success.
>
> The short answer is: you can't.  The devs use black backgrounds and
> you're supposed to also.
>
>> I already know about color.map but this just allows to tune some
>> colors and not all (at least the ones that are documented in the man
>> page).
>>
>> So, is there any way (without using --nocolor) to use color set that is
>> more readable?
>
> Nope.
>

You need to find a light color theme that works well. You should edit
your .Xdefaults (older documentation references .Xresources, which
does not seem to be parsed by some modern utilities or X11 servers) to
use that colorscheme. See the "export" tab on https://terminal.sexy/.

Pretty much every terminal should honor .Xdefaults, but if not, you
will need to change the colors in a menu.

If portage uses 256-color codes to specify an absolute color then that
should be changed, it makes the program unthemable via the standard
interface. It would also be an issue if portage used the less common
RGB color escapes.

Cheers,
 R0b0t1

Re: [gentoo-user] Re: emerge colors and light background

[John Blinka]

On Thu, Apr 19, 2018 at 10:36 AM, Grant Edwards
 wrote:
> On 2018-04-19, Klaus Ethgen  wrote:
>
>> I use light background and many colors of emerge and other tools are
>> simple unreadable (like light green).
>
> Yep, it's awful.  People have been complaining about it for years and
> years.
>
>> I searched how to adapt them to my background but did not success.
>
> The short answer is: you can't.  The devs use black backgrounds and
> you're supposed to also.
>
>> I already know about color.map but this just allows to tune some
>> colors and not all (at least the ones that are documented in the man
>> page).
>>
>> So, is there any way (without using --nocolor) to use color set that is
>> more readable?
>
> Nope.
>

My sympathies to the OP.  I fought against dark terminal backgrounds
for years (paper is white and ink is black, right?), tweaked all the
colors through every mechanism I knew of, and never did arrive at a
satisfactory result.  I finally decided to waste my time in other,
less frustrating pursuits, and turned all my backgrounds black.  Now
everything works perfectly, and I'm used to dark backgrounds.  Problem
solved.  You, of course, are free to prefer light backgrounds, but in
my experience Grant's answers ("You can't" and "Nope") sum up the
situation so precisely and succinctly that I just had to laugh
(thanks!).

John

[gentoo-user] Re: emerge colors and light background

[Grant Edwards]

On 2018-04-19, Neil Bothwick  wrote:
> On Thu, 19 Apr 2018 08:16:30 +0100, Klaus Ethgen wrote:
>
>> I use light background and many colors of emerge and other tools are
>> simple unreadable [...]

> I use a light background in my terminal and use color.map to deal with
> it. You can replace specific colours in color.map as well as changing
> colours for functions, such as:
>
> green = purple
> yellow=brown

Hmm. I never could get that to work acceptably, but maybe I should try
again. Does anybody have a color.map they'd care to share for
terminals with white backgrounds?

-- 
Grant Edwards   grant.b.edwardsYow! Isn't this my STOP?!
  at   
  gmail.com

[gentoo-user] Re: emerge colors and light background

[Grant Edwards]

On 2018-04-19, Klaus Ethgen  wrote:

> I use light background and many colors of emerge and other tools are
> simple unreadable (like light green).

Yep, it's awful.  People have been complaining about it for years and
years.

> I searched how to adapt them to my background but did not success.

The short answer is: you can't.  The devs use black backgrounds and
you're supposed to also.

> I already know about color.map but this just allows to tune some
> colors and not all (at least the ones that are documented in the man
> page).
>
> So, is there any way (without using --nocolor) to use color set that is
> more readable?

Nope.

-- 
Grant Edwards   grant.b.edwardsYow! I hope I bought the
  at   right relish ... z
  gmail.com...

Re: [gentoo-user] Re: emerge --oneshot portage

[thelma]

On 03/30/2018 08:01 AM, Kai Krakow wrote:
> Am Tue, 13 Mar 2018 14:52:34 -0600 schrieb thelma:
> 
>> Thelma
>> On 03/13/2018 12:11 PM, Neil Bothwick wrote:
>>> On Tue, 13 Mar 2018 11:36:12 -0600, the...@sys-concept.com wrote:
>>>
 sys-apps/portage:0

   (sys-apps/portage-2.3.16:0/0::gentoo, ebuild scheduled for merge)
 pulled in by sys-apps/portage (Argument)

   (sys-apps/portage-2.3.6:0/0::gentoo, installed) pulled in by
 
 sys-apps/portage[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)]
 required by (app-portage/gentoolkit-0.3.3:0/0::gentoo, installed)
>>>
>>> Your old version of gentoolkit (and other packages mentioned in the full
>>> output) is causing this. Trying to upgrade an out of date system
>>> piecemeal can cause this. Just do an emerge -u @system and let portage
>>> resolve these issues rather than trying to do it yourself.
>>
>> I spoke too soon.  Now, when I try: emerge -u @system
>> I'm getting an error as well.
>>
>> emerge -ua @system
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>>
>> WARNING: One or more updates/rebuilds have been skipped due to a dependency 
>> conflict:
>>
>> sys-libs/zlib:0
>>
>>   (sys-libs/zlib-1.2.11-r1:0/1::gentoo, ebuild scheduled for merge) 
>> conflicts with
>> >=sys-libs/zlib-1.2.8-r1:0/0=[abi_x86_32(-),abi_x86_64(-)] required by 
>> (media-libs/lcms-2.8-r1:2/2::gentoo, installed)
>> ^ 
> |
> Note this --+
> 
>>
>> sys-libs/readline:0
>>
>>   (sys-libs/readline-7.0_p3:0/7::gentoo, ebuild scheduled for merge) 
>> conflicts with
>> sys-libs/readline:0/0= required by (dev-lang/ruby-2.1.9:2.1/2.1::gentoo, 
>> installed)
>>  ^
>  |
> And this too +
> 
>> !!! The following update(s) have been skipped due to unsatisfied dependencies
>> !!! triggered by backtracking:
>>
>> app-shells/bash:0
> 
> Emerge seems to be unable to resolve subslot changes properly and
> doesn't issue a rebuild automatically for those. It's a headache I
> regularly have to deal with when upgrading Qt.
> 
> As you can see from the output, the subslot requirement changed from
> "0/0" (as required by lcms) to "0/1" (as required by your emerge
> request). Similar goes for readline and ruby.
> 
> As written in the other post, you can usually inject those reinstalls
> manually with:
> 
> # emerge ... --reinstall-atoms={lcms,ruby}
> 
> If you are using color output, these are usually easily spotted as
> they are the blue package names.

THANK YOU! for the explanation.
Finally somebody was able to explain it clearly.
I've added your explanation to my special notes.  Next time I'll know
what to do.

Happy Easter!
--
Thelma

[gentoo-user] Re: emerge --oneshot portage

[Kai Krakow]

Am Tue, 13 Mar 2018 14:52:34 -0600 schrieb thelma:

> Thelma
> On 03/13/2018 12:11 PM, Neil Bothwick wrote:
>> On Tue, 13 Mar 2018 11:36:12 -0600, the...@sys-concept.com wrote:
>> 
>>> sys-apps/portage:0
>>>
>>>   (sys-apps/portage-2.3.16:0/0::gentoo, ebuild scheduled for merge)
>>> pulled in by sys-apps/portage (Argument)
>>>
>>>   (sys-apps/portage-2.3.6:0/0::gentoo, installed) pulled in by
>>> 
>>> sys-apps/portage[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)]
>>> required by (app-portage/gentoolkit-0.3.3:0/0::gentoo, installed)
>> 
>> Your old version of gentoolkit (and other packages mentioned in the full
>> output) is causing this. Trying to upgrade an out of date system
>> piecemeal can cause this. Just do an emerge -u @system and let portage
>> resolve these issues rather than trying to do it yourself.
> 
> I spoke too soon.  Now, when I try: emerge -u @system
> I'm getting an error as well.
> 
> emerge -ua @system
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> 
> WARNING: One or more updates/rebuilds have been skipped due to a dependency 
> conflict:
> 
> sys-libs/zlib:0
> 
>   (sys-libs/zlib-1.2.11-r1:0/1::gentoo, ebuild scheduled for merge) conflicts 
> with
> >=sys-libs/zlib-1.2.8-r1:0/0=[abi_x86_32(-),abi_x86_64(-)] required by 
> (media-libs/lcms-2.8-r1:2/2::gentoo, installed)
> ^ 
|
Note this --+

> 
> sys-libs/readline:0
> 
>   (sys-libs/readline-7.0_p3:0/7::gentoo, ebuild scheduled for merge) 
> conflicts with
> sys-libs/readline:0/0= required by (dev-lang/ruby-2.1.9:2.1/2.1::gentoo, 
> installed)
>  ^
 |
And this too +

> !!! The following update(s) have been skipped due to unsatisfied dependencies
> !!! triggered by backtracking:
> 
> app-shells/bash:0

Emerge seems to be unable to resolve subslot changes properly and
doesn't issue a rebuild automatically for those. It's a headache I
regularly have to deal with when upgrading Qt.

As you can see from the output, the subslot requirement changed from
"0/0" (as required by lcms) to "0/1" (as required by your emerge
request). Similar goes for readline and ruby.

As written in the other post, you can usually inject those reinstalls
manually with:

# emerge ... --reinstall-atoms={lcms,ruby}

If you are using color output, these are usually easily spotted as
they are the blue package names.


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: emerge dev-hasell/stack fails with unclear error

[R0b0t1]

On Mon, Feb 26, 2018 at 11:59 PM,   wrote:
> On Monday, February 26, 2018 10:24:44 AM EST you wrote:
>> When emerging dev-haskell/stack-1.3.2 I'm getting:
>>
>> 
>> [ 84 of 121] Compiling Stack.Path   ( src/Stack/Path.hs,
>> dist/build/Stack/Path.o )
>> [ 85 of 121] Compiling Stack.Package( src/Stack/Package.hs,
>> dist/build/Stack/Package.o )
>> [100 of 121] Compiling Stack.Upload ( src/Stack/Upload.hs,
>> dist/build/Stack/Upload.o )
>> [101 of 121] Compiling Control.Concurrent.Execute (
>> src/Control/Concurrent/Execute.hs, dist/build/Control/Concurrent/Execute.o
>> )
>> * ERROR: dev-haskell/stack-1.3.2::gentoo failed (compile phase):
>> *   setup build failed
>> *
>> * Call stack:
>> * ebuild.sh, line  124:  Called src_compile
>> *   environment, line 2851:  Called haskell-cabal_src_compile
>> *   environment, line 2049:  Called cabal_src_compile
>> *   environment, line  771:  Called cabal-build
>> *   environment, line  535:  Called die
>> * The specific snippet of code:
>> *   ./setup "$@" || die "setup build failed"
>> *
>> 
>>
>> So _probably_ something went wrong when compiling Control.Concurrent.Execute
>> -- but I see no way to tell what was the problem. How do I debug this?
>>
>
> Well,
>
> cd /var/tmp/portage/dev-haskell/stack-1.3.2/work/stack-1.3.2
> runhaskell Setup build
>
> does show an error. It looks like package version mismatch, digging into it...
>
> Sorry for the noise. Strange that emerge did not show any error message from
> the compillation, though...
>
> --
> Anton
>

If you get anywhere, please let me know how. I found the project an
inscrutable mess.

Cheers,
 R0b0t1

[gentoo-user] Re: emerge dev-hasell/stack fails with unclear error

[anton . stay . connected]

On Monday, February 26, 2018 10:24:44 AM EST you wrote:
> When emerging dev-haskell/stack-1.3.2 I'm getting:
> 
> 
> [ 84 of 121] Compiling Stack.Path   ( src/Stack/Path.hs,
> dist/build/Stack/Path.o )
> [ 85 of 121] Compiling Stack.Package( src/Stack/Package.hs,
> dist/build/Stack/Package.o )
> [100 of 121] Compiling Stack.Upload ( src/Stack/Upload.hs,
> dist/build/Stack/Upload.o )
> [101 of 121] Compiling Control.Concurrent.Execute (
> src/Control/Concurrent/Execute.hs, dist/build/Control/Concurrent/Execute.o
> )
> * ERROR: dev-haskell/stack-1.3.2::gentoo failed (compile phase):
> *   setup build failed
> *
> * Call stack:
> * ebuild.sh, line  124:  Called src_compile
> *   environment, line 2851:  Called haskell-cabal_src_compile
> *   environment, line 2049:  Called cabal_src_compile
> *   environment, line  771:  Called cabal-build
> *   environment, line  535:  Called die
> * The specific snippet of code:
> *   ./setup "$@" || die "setup build failed"
> *
> 
> 
> So _probably_ something went wrong when compiling Control.Concurrent.Execute
> -- but I see no way to tell what was the problem. How do I debug this?
> 

Well,

cd /var/tmp/portage/dev-haskell/stack-1.3.2/work/stack-1.3.2
runhaskell Setup build

does show an error. It looks like package version mismatch, digging into it...

Sorry for the noise. Strange that emerge did not show any error message from 
the compillation, though...

-- 
Anton

Re: [gentoo-user] Re: emerge @preserved-rebuild failure

[zless]

În ziua de duminică, 7 ianuarie 2018, la 03:09:32 EET, Mart Raudsepp a scris:
> > To me this reads as readline-7.0_p3 depends on libs from readline-
> > 6.3.
> > 
> > Smells a bit as some sort of bug. Try rebuilding readline?
> > 
> > This didn't happen here when readline was bumped.
> 
> This is no bug here. It's just storing the fact that it preserved these
> /lib64/libreadline.so.6{,.3} under the replacing newer version package.
> That is, readline-7.0_p3 now owns these files, but based on this
> registry, they will be deleted and removed from its CONTENTS, once
> there are no more consumers of it based on essentially NEEDED.ELF.2
> contents in the VDB (/var/db/pkg/*/*/NEEDED.ELF.2).
> That is, what is keeping them from being removed is not stored in this
> registry.

Thanks for the in-depth explanation. Do you think that revdep-rebuild would've 
helped here?

And a bit off-topic for this thread (but it's a subject that interests me): 
does the preserved rebuild feature track user installed programs (outside of 
portage control)?

[gentoo-user] Re: emerge @preserved-rebuild failure

[Hartmut Figge]

Mart Raudsepp:

>Maybe there is just an old ruby:2.1 SLOT installed, that hasn't been
>properly depcleaned?

Indeed.

i5-64 /home/hafi # emerge -p -c
[...]

 dev-lang/ruby
selected: 2.1.9
   protected: none
 omitted: 2.2.9

[...]

After depclean, which required another @preserved-rebuild, a successful
one, I replaced the the now preserved_libs_registry with the problematic
old one. This time there was no problem.

i5-64 /home/hafi # emerge -q @preserved-rebuild
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) net-ftp/gftp-2.0.19-r3::gentoo
>>> Installing (1 of 1) net-ftp/gftp-2.0.19-r3::gentoo

:)

Hartmut

Re: [gentoo-user] Re: emerge @preserved-rebuild failure

[Mart Raudsepp]

On Sat, 2018-01-06 at 23:42 +0200, zless wrote:
> În ziua de sâmbătă, 6 ianuarie 2018, la 23:25:32 EET, Hartmut Figge a
> scris:
> > zless:
> > > Could you also take a look at the file
> > > /var/lib/portage/preserved_libs_registry ?
> > 
> > hafi@i5-64 ~ $ cat /var/lib/portage/preserved_libs_registry
> > {
> > "sys-libs/readline:0": [
> > "sys-libs/readline-7.0_p3",
> > "10658",
> > [
> > "/lib64/libreadline.so.6.3",
> > "/lib64/libreadline.so.6"
> > ]
> > ]
> > 
> 
> To me this reads as readline-7.0_p3 depends on libs from readline-
> 6.3.
> 
> Smells a bit as some sort of bug. Try rebuilding readline?
> 
> This didn't happen here when readline was bumped.

This is no bug here. It's just storing the fact that it preserved these
/lib64/libreadline.so.6{,.3} under the replacing newer version package.
That is, readline-7.0_p3 now owns these files, but based on this
registry, they will be deleted and removed from its CONTENTS, once
there are no more consumers of it based on essentially NEEDED.ELF.2
contents in the VDB (/var/db/pkg/*/*/NEEDED.ELF.2).
That is, what is keeping them from being removed is not stored in this
registry.

> > > It's like this when there are no preserved libs:
> > > 
> > > # cat preserved_libs_registry
> > 
> > I'm currently running 'find . -name '*preserved*' on / in the hope
> > of
> > finding the set with the preserverd libs *g* Well, I will let it
> > continue.

Maybe there is just an old ruby:2.1 SLOT installed, that hasn't been
properly depcleaned?


Mart

Re: [gentoo-user] Re: emerge @preserved-rebuild failure

[zless]

În ziua de sâmbătă, 6 ianuarie 2018, la 23:51:59 EET, Hartmut Figge a scris:
> Hrm. Replacing the obviously corrupt preserved_libs_registry with the
> clean one from my backup? That would be the end of the investigation.

You could also check if those readline-6 preserved libs really exist:

/lib64/libreadline.so.6.3
/lib64/libreadline.so.6

Try renaming them or backing them up somewhere else and see if realine 
applications (bash) still work fine after that.

Other than that... I'd fill a bug about this ;)

[gentoo-user] Re: emerge @preserved-rebuild failure

[Hartmut Figge]

zless:

>Smells a bit as some sort of bug. Try rebuilding readline?

That's what I hesitated to do in fear of blurring clues. Done.

i5-64 /home/hafi # emerge -q readline
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) sys-libs/readline-7.0_p3::gentoo
>>> Installing (1 of 1) sys-libs/readline-7.0_p3::gentoo
>>> Recording sys-libs/readline in "world" favorites file...

!!! existing preserved libs found

Hrm. Replacing the obviously corrupt preserved_libs_registry with the
clean one from my backup? That would be the end of the investigation.

Hartmut

Re: [gentoo-user] Re: emerge @preserved-rebuild failure

[zless]

În ziua de sâmbătă, 6 ianuarie 2018, la 23:25:32 EET, Hartmut Figge a scris:
> zless:
> >Could you also take a look at the file
> >/var/lib/portage/preserved_libs_registry ?
> 
> hafi@i5-64 ~ $ cat /var/lib/portage/preserved_libs_registry
> {
> "sys-libs/readline:0": [
> "sys-libs/readline-7.0_p3",
> "10658",
> [
> "/lib64/libreadline.so.6.3",
> "/lib64/libreadline.so.6"
> ]
> ]
> 

To me this reads as readline-7.0_p3 depends on libs from readline-6.3.

Smells a bit as some sort of bug. Try rebuilding readline?

This didn't happen here when readline was bumped.


> >It's like this when there are no preserved libs:
> >
> ># cat preserved_libs_registry
> 
> I'm currently running 'find . -name '*preserved*' on / in the hope of
> finding the set with the preserverd libs *g* Well, I will let it continue.
> 
> Hartmut

[gentoo-user] Re: emerge @preserved-rebuild failure

[Hartmut Figge]

zless:

>Could you also take a look at the file
>/var/lib/portage/preserved_libs_registry ?

hafi@i5-64 ~ $ cat /var/lib/portage/preserved_libs_registry
{
"sys-libs/readline:0": [
"sys-libs/readline-7.0_p3",
"10658",
[
"/lib64/libreadline.so.6.3",
"/lib64/libreadline.so.6"
]
]

>It's like this when there are no preserved libs:
>
># cat preserved_libs_registry

I'm currently running 'find . -name '*preserved*' on / in the hope of
finding the set with the preserverd libs *g* Well, I will let it continue.

Hartmut

Re: [gentoo-user] Re: emerge @preserved-rebuild failure

[zless]

În ziua de sâmbătă, 6 ianuarie 2018, la 23:04:21 EET, Hartmut Figge a scris:
> There is no rest. I can give the whole output for the last emerge
> command which ended with the above line. Doubt that will be helpful.

Could you also take a look at the file
/var/lib/portage/preserved_libs_registry ?

It's like this when there are no preserved libs:

# cat preserved_libs_registry
{}

[gentoo-user] Re: emerge @preserved-rebuild failure

[Hartmut Figge]

Neil Bothwick:
>On Sat, 6 Jan 2018 21:21:16 +0100, Hartmut Figge wrote:

>> Mostly stable Gentoo. After having fun with linguas *g*
>> 
>> !!! existing preserved libs found
>
>What's the rest of this output, it should list the packages and files
>involved.

There is no rest. I can give the whole output for the last emerge
command which ended with the above line. Doubt that will be helpful.

i5-64 /home/hafi # USE="linguas_de linguas_en linguas_en_US" emerge -pq
-uDN @world
[ebuild   R   ] sys-apps/pv-1.6.0-r1
[ebuild   R   ] net-analyzer/nmap-7.40
[ebuild   R   ] sys-apps/shadow-4.5
[ebuild   R   ] media-video/vlc-2.2.8
[ebuild   R   ] app-emulation/wine-vanilla-2.22
[ebuild   R   ] app-emulation/wine-d3d9-2.21
[ebuild   R   ] app-emulation/wine-any-2.21
[ebuild   R   ] app-text/qpdfview-0.4.16
[ebuild   R   ] sys-apps/lshw-02.18b
[ebuild  rR   ] app-crypt/gnupg-2.2.0
[ebuild U ] sys-block/gparted-0.29.0 [0.27.0]
[ebuild   R   ] media-gfx/gimp-2.8.22
[ebuild U ] app-crypt/gpgme-1.10.0 [1.8.0-r3]
[ebuild  rR   ] net-print/gutenprint-5.2.12
i5-64 /home/hafi # USE="linguas_de linguas_en linguas_en_US" emerge -q
-uDN --keep-going @world
[ebuild   R   ] sys-apps/pv-1.6.0-r1
[ebuild   R   ] net-analyzer/nmap-7.40
[ebuild   R   ] sys-apps/shadow-4.5
[ebuild   R   ] media-video/vlc-2.2.8
[ebuild   R   ] app-emulation/wine-vanilla-2.22
[ebuild   R   ] app-emulation/wine-d3d9-2.21
[ebuild   R   ] app-emulation/wine-any-2.21
[ebuild   R   ] app-text/qpdfview-0.4.16
[ebuild   R   ] sys-apps/lshw-02.18b
[ebuild  rR   ] app-crypt/gnupg-2.2.0
[ebuild U ] sys-block/gparted-0.29.0 [0.27.0]
[ebuild   R   ] media-gfx/gimp-2.8.22
[ebuild U ] app-crypt/gpgme-1.10.0 [1.8.0-r3]
[ebuild  rR   ] net-print/gutenprint-5.2.12
>>> Verifying ebuild manifests
>>> Running pre-merge checks for app-emulation/wine-vanilla-2.22
>>> Running pre-merge checks for app-emulation/wine-d3d9-2.21
>>> Running pre-merge checks for app-emulation/wine-any-2.21
>>> Emerging (1 of 14) sys-apps/pv-1.6.0-r1::gentoo
>>> Installing (1 of 14) sys-apps/pv-1.6.0-r1::gentoo
>>> Emerging (2 of 14) net-analyzer/nmap-7.40::gentoo
>>> Installing (2 of 14) net-analyzer/nmap-7.40::gentoo
>>> Emerging (3 of 14) sys-apps/shadow-4.5::gentoo
>>> Installing (3 of 14) sys-apps/shadow-4.5::gentoo
>>> Emerging (4 of 14) media-video/vlc-2.2.8::gentoo
>>> Installing (4 of 14) media-video/vlc-2.2.8::gentoo
>>> Emerging (5 of 14) app-emulation/wine-vanilla-2.22::x-portage
>>> Installing (5 of 14) app-emulation/wine-vanilla-2.22::x-portage
>>> Emerging (6 of 14) app-emulation/wine-d3d9-2.21::x-portage
>>> Installing (6 of 14) app-emulation/wine-d3d9-2.21::x-portage
>>> Emerging (7 of 14) app-emulation/wine-any-2.21::x-portage
>>> Installing (7 of 14) app-emulation/wine-any-2.21::x-portage
>>> Emerging (8 of 14) app-text/qpdfview-0.4.16::gentoo
>>> Installing (8 of 14) app-text/qpdfview-0.4.16::gentoo
>>> Emerging (9 of 14) sys-apps/lshw-02.18b::gentoo
>>> Installing (9 of 14) sys-apps/lshw-02.18b::gentoo
>>> Emerging (10 of 14) app-crypt/gnupg-2.2.0::gentoo
>>> Installing (10 of 14) app-crypt/gnupg-2.2.0::gentoo
>>> Emerging (11 of 14) sys-block/gparted-0.29.0::gentoo
>>> Installing (11 of 14) sys-block/gparted-0.29.0::gentoo
>>> Emerging (12 of 14) media-gfx/gimp-2.8.22::gentoo
>>> Installing (12 of 14) media-gfx/gimp-2.8.22::gentoo
>>> Emerging (13 of 14) app-crypt/gpgme-1.10.0::gentoo
>>> Installing (13 of 14) app-crypt/gpgme-1.10.0::gentoo
>>> Emerging (14 of 14) net-print/gutenprint-5.2.12::gentoo
>>> Installing (14 of 14) net-print/gutenprint-5.2.12::gentoo

 * Messages for package net-print/gutenprint-5.2.12:

 * Updating installed printer ppd files
 * Did not update any PPD files

!!! existing preserved libs found

>> i5-64 /home/hafi # emerge -q @preserved-rebuild
>> 
>> emerge: there are no ebuilds to satisfy "dev-lang/ruby:2.1".
>> (dependency required by "@preserved-rebuild" [argument])
>
>Something appears to be asking for an old Ruby, hopefully the output will
>show why.

Sadly there is no more output. Even 'emerge -v @preserved-rebuild' does
not give more.

>Also, what does emerge --info show for RUBY_TARGETS

RUBY_TARGETS="ruby22"

>and do you have asetting fo r it in make.conf?

No.

Another info:
hafi@i5-64 ~ $ emerge --version
Portage 2.3.13 (python 2.7.14-final-0, default/linux/amd64/17.0,
gcc-6.4.0, glibc-2.25-r9, 4.9.72-gentoo x86_64)

Hartmut

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] 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.

[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] 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.

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

[Ian Zimmerman]

On 2017-12-05 14:02, Peter Humphrey wrote:

> > [0] http://people.redhat.com/drepper/dsohowto.pdf
> 
> Ah. Right. I see now.

The error message you're showing probably means that -fpic is in effect
when in fact -fPIC is needed.  Quoting the gcc manual:

 If the GOT size for the linked executable exceeds a machine-specific
 maximum size, you get an error message from the linker indicating that
 `-fpic' does not work; in that case, recompile with `-fPIC' instead.

-- 
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: Emerge does want to tell me...what?

[Raffaele Belardi]

Peter Humphrey wrote:
> On Tuesday, 5 December 2017 10:23:30 GMT Peter Humphrey wrote:
> 
>> I've been waiting for shouts of horror at that suggestion, but all's quiet
>> so I'll see if I can remember how to set -fpic in the environment of
>> palemoon. I'd have expected the ebuild do that though.
> 
> OK, I've done that and now I get these errors:
> 
> [...]
> 10:08.72 ../../build/unix/gold/ld: error: /var/tmp/portage/www-client/
> palemoon-27.6.2/work/palemoon-27.6.2/o/toolkit/library/../../media/
> libstagefright/Unified_cpp_media_libstagefright0.o: requires dynamic 
> R_X86_64_PC32 reloc against '_Z13GetDemuxerLogv' which may overflow at 
> runtime; recompile with -fPIC
> 10:08.72 ../../build/unix/gold/ld: error: read-only segment has dynamic 
> relocations
> 10:08.72 /var/tmp/portage/www-client/palemoon-27.6.2/work/palemoon-27.6.2/
> media/libstagefright/binding/MoofParser.cpp:767: error: undefined reference 
> to 'GetDemuxerLog()'
> [...]
> 
> I can't see how an undefined reference can be due to my environment, or can 
> it?
> 

The real error is few lines above and the solution suggested: 'recompile with 
-fPIC'. ld
does not find a suitable GetDemuxerLog due to that error. Looks like your -fpic
modification did not make it through.

raffaele

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

[Peter Humphrey]

On Tuesday, 5 December 2017 10:23:30 GMT Peter Humphrey wrote:

> I've been waiting for shouts of horror at that suggestion, but all's quiet
> so I'll see if I can remember how to set -fpic in the environment of
> palemoon. I'd have expected the ebuild do that though.

OK, I've done that and now I get these errors:

[...]
10:08.72 ../../build/unix/gold/ld: error: /var/tmp/portage/www-client/
palemoon-27.6.2/work/palemoon-27.6.2/o/toolkit/library/../../media/
libstagefright/Unified_cpp_media_libstagefright0.o: requires dynamic 
R_X86_64_PC32 reloc against '_Z13GetDemuxerLogv' which may overflow at 
runtime; recompile with -fPIC
10:08.72 ../../build/unix/gold/ld: error: read-only segment has dynamic 
relocations
10:08.72 /var/tmp/portage/www-client/palemoon-27.6.2/work/palemoon-27.6.2/
media/libstagefright/binding/MoofParser.cpp:767: error: undefined reference 
to 'GetDemuxerLog()'
[...]

I can't see how an undefined reference can be due to my environment, or can 
it?

-- 
Regards,
Peter.

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

[Peter Humphrey]

On Tuesday, 5 December 2017 13:18:59 GMT Michael Orlitzky wrote:
> On 12/05/2017 05:23 AM, Peter Humphrey wrote:
> > I've been waiting for shouts of horror at that suggestion, but all's
> > quiet so I'll see if I can remember how to set -fpic in the environment
> > of palemoon. I'd have expected the ebuild do that though.
> 
> The upstream build system should already be using -fpic for any of its
> shared objects[0]:
> 
>   The most important recommendation is to always use
>   -fpic or -fPIC when generating code which ends up in
>   DSOs. This applies to data as well as code... When gcc
>   is used... It is therefore mandatory to compile all
>   code which can potentially end up in a DSO with
>   -fpic/-fPIC since otherwise the DSO might not work
>   correctly.
> 
> If -fpic is missing, it's probably a bug in some Makefile. The ebuild
> *can* fix that in the meantime, but it belongs upstream.
> 
> 
> [0] http://people.redhat.com/drepper/dsohowto.pdf

Ah. Right. I see now.

-- 
Regards,
Peter.

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

[Michael Orlitzky]

On 12/05/2017 05:23 AM, Peter Humphrey wrote:
> 
> I've been waiting for shouts of horror at that suggestion, but all's quiet 
> so I'll see if I can remember how to set -fpic in the environment of 
> palemoon. I'd have expected the ebuild do that though.

The upstream build system should already be using -fpic for any of its
shared objects[0]:

  The most important recommendation is to always use
  -fpic or -fPIC when generating code which ends up in
  DSOs. This applies to data as well as code... When gcc
  is used... It is therefore mandatory to compile all
  code which can potentially end up in a DSO with
  -fpic/-fPIC since otherwise the DSO might not work
  correctly.

If -fpic is missing, it's probably a bug in some Makefile. The ebuild
*can* fix that in the meantime, but it belongs upstream.


[0] http://people.redhat.com/drepper/dsohowto.pdf

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

[Peter Humphrey]

On Monday, 4 December 2017 19:19:33 GMT Walter Dnes wrote:
> On Mon, Dec 04, 2017 at 10:34:48AM +, Peter Humphrey wrote
> 
> > It doesn't build here; I get a few errors, thus:
> >  9:41.58 ../../build/unix/gold/ld: error: /var/tmp/portage/www-client/
> > 
> > palemoon-27.6.2/work/palemoon-27.6.2/o/toolkit/library/../../media/
> > libstagefright/Unified_cpp_media_libstagefright0.o: requires dynamic
> > R_X86_64_PC32 reloc against '_Z13GetDemuxerLogv' which may overflow at
> > runtime; recompile with -fPIC
> 
>
>
> 
>   GCC is giving you a hint.  Actually, I've run into other stuff in
> Gentoo that breaks with PIE and PIC.  Google is full of complaints for
> other distros.  I'm seriously considering sticking "-fno-pic -fno-pie"
> into CFLAGS/CXXFLAGS before migrating to 17.0.

I've been waiting for shouts of horror at that suggestion, but all's quiet 
so I'll see if I can remember how to set -fpic in the environment of 
palemoon. I'd have expected the ebuild do that though.

> And it'll also save me from rebuilding everything on every machine.  My
> ancient netbook with 2 gigs of ram will thank me.

-- 
Regards,
Peter.

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

[Walter Dnes]

On Mon, Dec 04, 2017 at 02:19:33PM -0500, Walter Dnes wrote
> On Mon, Dec 04, 2017 at 10:34:48AM +, Peter Humphrey wrote
> 
> > It doesn't build here; I get a few errors, thus:
> > 
> >  9:41.58 ../../build/unix/gold/ld: error: /var/tmp/portage/www-client/
> > palemoon-27.6.2/work/palemoon-27.6.2/o/toolkit/library/../../media/
> > libstagefright/Unified_cpp_media_libstagefright0.o: requires dynamic 
> > R_X86_64_PC32 reloc against '_Z13GetDemuxerLogv' which may overflow at 
> > runtime; recompile with -fPIC
>
>
> 
>   GCC is giving you a hint.  Actually, I've run into other stuff in
> Gentoo that breaks with PIE and PIC.  Google is full of complaints for
> other distros.  I'm seriously considering sticking "-fno-pic -fno-pie"
> into CFLAGS/CXXFLAGS before migrating to 17.0.  And it'll also save me
> from rebuilding everything on every machine.  My ancient netbook with 2
> gigs of ram will thank me.

  While we're at it, throw "-pic" into USE, to speed up the
non-pic/non-pie system...

[d531][waltdnes][~] grep -i ":pic - disable" 
/usr/portage/profiles/use.local.desc
app-arch/gzip:pic - disable optimized assembly code that is not PIC friendly
dev-util/electron:pic - Disable optimized assembly code that is not PIC friendly
games-emulation/yabause:pic - disable optimized assembly code that is not PIC 
friendly
games-fps/duke3d:pic - disable optimized assembly code that is not PIC friendly
media-libs/mesa:pic - disable optimized assembly code that is not PIC friendly
media-libs/x264:pic - disable optimized assembly code that is not PIC friendly
media-libs/x265:pic - Disable optimized assembly code that is not PIC friendly
media-libs/xvid:pic - disable optimized assembly code that is not PIC friendly
media-video/transcode:pic - disable optimized assembly code that is not PIC 
friendly
www-client/chromium:pic - Disable optimized assembly code that is not PIC 
friendly

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

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

[Walter Dnes]

On Mon, Dec 04, 2017 at 10:34:48AM +, Peter Humphrey wrote

> It doesn't build here; I get a few errors, thus:
> 
>  9:41.58 ../../build/unix/gold/ld: error: /var/tmp/portage/www-client/
> palemoon-27.6.2/work/palemoon-27.6.2/o/toolkit/library/../../media/
> libstagefright/Unified_cpp_media_libstagefright0.o: requires dynamic 
> R_X86_64_PC32 reloc against '_Z13GetDemuxerLogv' which may overflow at 
> runtime; recompile with -fPIC
   
   

  GCC is giving you a hint.  Actually, I've run into other stuff in
Gentoo that breaks with PIE and PIC.  Google is full of complaints for
other distros.  I'm seriously considering sticking "-fno-pic -fno-pie"
into CFLAGS/CXXFLAGS before migrating to 17.0.  And it'll also save me
from rebuilding everything on every machine.  My ancient netbook with 2
gigs of ram will thank me.

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

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

[Peter Humphrey]

On Sunday, 3 December 2017 17:58:53 GMT Simon Thelen wrote:
> On 17-12-03 at 09:52, Ian Zimmerman wrote:
> > On 2017-12-03 06:46, Heiko Baums wrote:
> > > 1. It can't find >=sys-devel/gcc-6.4.0 but only older gcc versions.
> > > 
> > > 2. You have installed a package that depend on sys-devel/gcc-5.4.0-r3
> > > or sys-devel/gcc-4.9.4.
> > > 
> > > I already explained what you can do in the first case. In the second
> > > case I would try to fix (uninstall, rebuild, upgrade or whatever)
> > > those packages which depend on an outdated gcc. I guess equery is your
> > > friend.
> > 
> > Those include palemoon.  GL with fixing that.
> 
> Palemoon builds fine with gcc 6.4.0 (just not with gcc 7.2.0), if the
> ebuild you're using requires an older gcc it's either wrong or doing
> something weird.

It doesn't build here; I get a few errors, thus:

 9:41.58 ../../build/unix/gold/ld: error: /var/tmp/portage/www-client/
palemoon-27.6.2/work/palemoon-27.6.2/o/toolkit/library/../../media/
libstagefright/Unified_cpp_media_libstagefright0.o: requires dynamic 
R_X86_64_PC32 reloc against '_Z13GetDemuxerLogv' which may overflow at 
runtime; recompile with -fPIC
 9:41.58 ../../build/unix/gold/ld: error: read-only segment has dynamic 
relocations
 9:41.58 /var/tmp/portage/www-client/palemoon-27.6.2/work/palemoon-27.6.2/
media/libstagefright/binding/MoofParser.cpp:767: error: undefined reference 
to 'GetDemuxerLog()'
...
ERROR: www-client/palemoon-27.6.2::palemoon failed (compile phase)

This is after upgrading to the 17.0 plasma profile, as instructed in the 
news item. Does it warrant a bug report?

-- 
Regards,
Peter.

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

[Simon Thelen]

On 17-12-03 at 12:06, Ian Zimmerman wrote:
> On 2017-12-03 18:58, Simon Thelen wrote:
> 
> > Palemoon builds fine with gcc 6.4.0 (just not with gcc 7.2.0), if the
> > ebuild you're using requires an older gcc it's either wrong or doing
> > something weird.
> It builds, but the result binary crashes every 10 minutes.  Have you
> tried it?
I have had similar issues, but gcc 6.4.0 isn't the (sole) reproducer.

I have 2 systems, a haswell laptop and a Ryzen desktop.
Palemoon works fine built using gcc 6.4.0 on the laptop.
On the desktop, however, I had regularly occurring segfaults that
occurred whenever I ran palemoon and had the ulimit for core dumps set
to 0 (ulimit -c to any other value and the segfaults would not occur). I
managed to "fix" the segfaulting by compiling palemoon with CFLAGS="-O1"
instead of "-O2".
I never tried reproducing with an older gcc or clang as the issue only
popped up when I rebuilt my desktop for the Ryzen CPU (switched from
Nehalem where everything worked fine).

Another person I know who uses palemoon on Gentoo has also had no issues
with palemoon built against gcc 6.4.0 on an Xeon with Haswell
architecture.

I assumed this was an issue just with my machine since I could not
reproduce it anywhere else. It might be that palemoon has issues with
certain optimizations/instruction sets that are aggravated by using
newer gcc versions (which could turn on optimizations by default etc).

I tried checking when/why the GCC_SUPPORTED_VERSIONS was added to the
palemoon overlay ebuilds, but can't find an issue or commit introducing
it (didn't spend that long checking), but if I'm not the only one
affected by this it might be worth it to open an issue with upstream.

> The ebuild from the palemoon overlay explicitly checks for the gcc
> version and refuses to proceed if it's newer then 4.9.4.  I have
> wondered why, but now I know.
If you are on Ryzen (or potentially any architecture that isn't
Nehalem-Haswell) you could try seeing if it's the same issue I
experienced (testing with `ulimit -c unlimited', recompiling with -O1),
otherwise you could try out the ebuild I maintain at [1] which may have
some differences from the one in the palemoon overlay.

[1]: 
https://git.c-14.de/landsraad.git/tree/www-client/palemoon/palemoon-27.6.2.ebuild

-- 
Simon Thelen

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

[Ian Zimmerman]

On 2017-12-03 18:58, Simon Thelen wrote:

> Palemoon builds fine with gcc 6.4.0 (just not with gcc 7.2.0), if the
> ebuild you're using requires an older gcc it's either wrong or doing
> something weird.

It builds, but the result binary crashes every 10 minutes.  Have you
tried it?

The ebuild from the palemoon overlay explicitly checks for the gcc
version and refuses to proceed if it's newer then 4.9.4.  I have
wondered why, but now I know.

-- 
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: Emerge does want to tell me...what?

[Simon Thelen]

On 17-12-03 at 09:52, Ian Zimmerman wrote:
> On 2017-12-03 06:46, Heiko Baums wrote:
> 
> > 1. It can't find >=sys-devel/gcc-6.4.0 but only older gcc versions.
> > 
> > 2. You have installed a package that depend on sys-devel/gcc-5.4.0-r3
> > or sys-devel/gcc-4.9.4.
> > 
> > I already explained what you can do in the first case. In the second
> > case I would try to fix (uninstall, rebuild, upgrade or whatever)
> > those packages which depend on an outdated gcc. I guess equery is your
> > friend.
> Those include palemoon.  GL with fixing that.
Palemoon builds fine with gcc 6.4.0 (just not with gcc 7.2.0), if the
ebuild you're using requires an older gcc it's either wrong or doing
something weird.

-- 
Simon Thelen

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

[Ian Zimmerman]

On 2017-12-03 06:46, Heiko Baums wrote:

> 1. It can't find >=sys-devel/gcc-6.4.0 but only older gcc versions.
> 
> 2. You have installed a package that depend on sys-devel/gcc-5.4.0-r3
> or sys-devel/gcc-4.9.4.
> 
> I already explained what you can do in the first case. In the second
> case I would try to fix (uninstall, rebuild, upgrade or whatever)
> those packages which depend on an outdated gcc. I guess equery is your
> friend.

Those include palemoon.  GL with fixing that.

I'm keeping the old profile for now, but when I switch I'll have to
unmask one of the old compilers.

-- 
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: emerge firefox-52.4.0 compile failure

[mad.scientist.at.large]

it's worth noting that a failing power supply can produce what seem to be ram 
problems.  it happened to me, swapping ram, a motherboard and then a power 
supply made it clear.

--
Note the right side (his right) of Mr. Trumps face, He's clearly had a major 
stroke or similar neurological insult.   The eye always droops, and that side 
of his mouth hardly moves when he speaks.  I try not to throw stones from 
inside my glass house, others obviously don't mind hypocrisy.


8. Oct 2017 18:14 by r03...@gmail.com:


> On Sun, Oct 8, 2017 at 4:53 PM, Grant Edwards <> grant.b.edwa...@gmail.com> > 
> wrote:
>> On 2017-10-08, R0b0t1 <>> r03...@gmail.com>> > wrote:
>>
>>> Usually what happens is it will be corrupted in RAM after being
>>> verified on disk, and faulty results will be saved to disk from RAM. A
>>> user on the forums recently had this issue compiling dev-lang/vala,
>>> and I have had related issues.
>>
>> I've had failing RAM corrupt files and cause compile failures (and
>> various other odd problems). But, the exact symptoms tend to be pretty
>> random.  The chances are infinitesmal that a HW problem would corrupt
>> the download (or the compile itself) in an identical manner a second
>> time.
>>
>
> Right, redownloading or rerunning the compilation usually fixes such
> issues. At the same time, I have seen people hit bad areas of RAM
> repeatedly and have it look like other errors.
> --snip
> Cheers,
> R0b0t1

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-11, R0b0t1  wrote:
> On Tue, Oct 10, 2017 at 6:30 PM, Peter Humphrey  wrote:
>> What's called Management in ISO9000.
>
> ISO9000 still lets you shoot yourself in the foot. You just wrote
> down that you were going to shoot yourself in the foot well in
> advance.

Yep.  As somebody involved in the ISO9000 effort at a large
manufacturer once told me: "Being ISO9000 compliant doesn't prevent
you from shipping low-quality crap products.  It just means that you
_know_ you're shipping low-quality crap products."

The assumption presumably being that your _customers_ could also
figure that out from reviewing your ISO9000 documentation.  I have no
idea how many customers actually do a good enough review of their
vendors' ISO9000 documents to figure it out...

-- 
Grant Edwards   grant.b.edwardsYow! Inside, I'm already
  at   SOBBING!
  gmail.com

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Peter Humphrey]

On Wednesday, 11 October 2017 04:02:36 BST R0b0t1 wrote:
> On Tue, Oct 10, 2017 at 6:30 PM, Peter Humphrey  
> wrote:
> > What's called Management in ISO9000.
> 
> ISO9000 still lets you shoot yourself in the foot. You just wrote down
> that you were going to shoot yourself in the foot well in advance.

It aims to ensure that what is produced is exactly what is intended. If 
shooting yourself in the foot is a credible business objective, so be it, 
but you'd have trouble showing how the business would benefit from it, or in 
persuading an auditor. Or the shareholders in the business, for that matter.

ISO9000 operates at company management level, not programmer level.

Actually, I can't be authoritative on ISO 9000 today; my experience dates 
back 20 years, to when I got a varied group of 100 software people through 
an audit against ISO 9001 (long story, not relevant here). I don't suppose 
the principles will have changed much though.

-- 
Regards,
Peter.

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[R0b0t1]

On Tue, Oct 10, 2017 at 6:30 PM, Peter Humphrey  wrote:
> What's called Management in ISO9000.
>

ISO9000 still lets you shoot yourself in the foot. You just wrote down
that you were going to shoot yourself in the foot well in advance.

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Peter Humphrey]

On Tuesday, 10 October 2017 11:46:22 BST Neil Bothwick wrote:
> On Mon, 9 Oct 2017 19:20:53 + (UTC), Grant Edwards wrote:
> > It turns out that over the past week or so, there have been several
> > 
> > _different_ firefox ebuilds released.  One of them was broken:
> >   Version 52.4.0 (Oct 3) was OK.
> >   
> >   Version 52.4.0 (Oct 7) was broken.
> >   
> >   Version 52.4.0 (Oct 9) is OK.
> > 
> > You (and I) had successfully installed the Oct 3 version of 52.4.0,
> > but when I tried to install the Oct 7 version of 52.4.0, it failed.
> > The Oct 9 version is supposed to be fixed. I don't really see how you
> > can repeatedly release new versions of something without changing the
> > version number, but maybe that's just me...
> 
> It depends on the breakage. If the installed program is broken it should
> be bumped, but if the breakage only relates to the build in some
> circumstances, it makes sense not to bump it. Otherwise everyone that
> installed the first time, maybe because they had the necessary
> dependencies already, would have to re-emerge the package another two
> times for no benefit.
> 
> If they truly were new versions it would be different, but all the ebuilds
> resulted in the same version of the software being installed.

I see what you mean, but in that case the development management model is 
broken. It's sacrificing correctness and rigour to convenience. It needs a 
review at the highest level. What's called Management in ISO9000.

-- 
Regards,
Peter.

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Marc Joliet]

Am Dienstag, 10. Oktober 2017, 12:27:25 CEST schrieb Marc Joliet:
> (Note that it does *not* search the description by default, and doesn't
> claim to, either!)

Ha, I tried to find a way to search only the description, but came up empty 
(you *can* search the description by searching through all comments, though).  
I then found this: 
https://stackoverflow.com/questions/33493375/bugzilla-how-to-search-in-the-description-of-the-bug-reports.
  Does anybody on this list 
know if it's possible?  Maybe in newer versions of bugzilla?  (I vaguely 
remember that Gentoo runs an older one.)

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


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

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Neil Bothwick]

On Mon, 9 Oct 2017 19:20:53 + (UTC), Grant Edwards wrote:

> It turns out that over the past week or so, there have been several
> _different_ firefox ebuilds released.  One of them was broken:
> 
>   Version 52.4.0 (Oct 3) was OK.
> 
>   Version 52.4.0 (Oct 7) was broken.
> 
>   Version 52.4.0 (Oct 9) is OK.
> 
> You (and I) had successfully installed the Oct 3 version of 52.4.0,
> but when I tried to install the Oct 7 version of 52.4.0, it failed.
> The Oct 9 version is supposed to be fixed. I don't really see how you
> can repeatedly release new versions of something without changing the
> version number, but maybe that's just me...

It depends on the breakage. If the installed program is broken it should
be bumped, but if the breakage only relates to the build in some
circumstances, it makes sense not to bump it. Otherwise everyone that
installed the first time, maybe because they had the necessary
dependencies already, would have to re-emerge the package another two
times for no benefit.

If they truly were new versions it would be different, but all the ebuilds
resulted in the same version of the software being installed.


-- 
Neil Bothwick

Puns are bad, but poetry is verse...


pgpgALZN7yARx.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Marc Joliet]

Am Dienstag, 10. Oktober 2017, 02:57:21 CEST schrieb Grant Edwards:
> On 2017-10-09, R0b0t1  wrote:
> > On Monday, October 9, 2017, Grant Edwards  
wrote:
> >> On 2017-10-09, allan gottlieb  wrote:
> >>> This is a know bug see https://bugs.gentoo.org/633790
> >> 
> >> Yep, that's it.  Yet when you search for roundingflags or
> >> shapedtextflags in Gentoo's bugzilla, it finds nothing.  Has the
> >> search feature in Bugzilla ever worked?
> > 
> > It's pretty limited.

Do you still think so when you consider the advanced search (or the saved 
search feature)?  Just curious, since I don't tend to perform complicated 
searches in any of the bug trackers I use.

> You're being too kind.  It's broken.  According to the bugzilla web
> page, the search includes the summary/description (as one might
> expect), but it doesn't actually _do_ that.

It does exactly what it says, e.g., when I search for qt I see:

" Status: UNCONFIRMED, CONFIRMED, IN_PROGRESS Alias: qt Summary: qt "

And it shows me exactly that: bugs with qt in the summary or as part of the 
alias that have their status set to UNCONFIRMED, CONFIRMED, or IN_PROGRESS.  
(Note that it does *not* search the description by default, and doesn't claim 
to, either!)

Now, it could be that other search filters are preventing you from finding 
bugs.  For example, as in my above example, bugs with their status set to 
"RESOLVED" or "VERIFIED" are not searched by default (searching only for 
VERIFIED found 120 additional bugs).  Or, more likely, your search strings 
simply aren't part of the summary.

Of course, it's not like I actively like bugzilla, but it's not quite 
"broken", either.  "Baroque" might be a better word ;) .

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


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

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Marc Joliet]

Am Dienstag, 10. Oktober 2017, 11:19:02 CEST schrieb Peter Humphrey:
> On Monday, 9 October 2017 20:20:53 BST Grant Edwards wrote:
> > I don't really see how you can repeatedly release new versions of
> > something without changing the version number, but maybe that's just me...
> 
> No, it isn't just you. What you describe is a classic example of a developer
> trying to hide his mistakes - strictly unprofessional. It would not have
> been allowed anywhere I've worked.
> 
> I know that volunteers are hard to find, but even so ...
> 
> Good work spotting the trail, by the way.

It's actually simpler than that: ebuilds do not need a revision bump when 
fixing compilation errors, since the ebuild remains uninstalled [0].  And if 
you /were/ able to build it, you won't profit from a revbump, either (in fact, 
people tend to loudly complain about unnecessary rebuilds).  So, no, it most 
likely is /not/ someone trying to hide their mistakes.  Never mind that the 
changes are easy to find in Gentoo's version control history [1], which 
references bug #633640, which in turn reveals that they were trying to fix a 
build error, but accidentally caused another in the process.  So, yeah, so 
much hiding going on here!

[0] https://devmanual.gentoo.org/general-concepts/ebuild-revisions/
[1] https://gitweb.gentoo.org/repo/gentoo.git/log/?qt=grep=firefox

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


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

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Peter Humphrey]

On Monday, 9 October 2017 20:20:53 BST Grant Edwards wrote:

> I don't really see how you can repeatedly release new versions of
> something without changing the version number, but maybe that's just me...

No, it isn't just you. What you describe is a classic example of a developer 
trying to hide his mistakes - strictly unprofessional. It would not have 
been allowed anywhere I've worked.

I know that volunteers are hard to find, but even so ...

Good work spotting the trail, by the way.

-- 
Regards,
Peter.

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[R0b0t1]

On Mon, Oct 9, 2017 at 7:57 PM, Grant Edwards  wrote:
> On 2017-10-09, R0b0t1  wrote:
>> On Monday, October 9, 2017, Grant Edwards  wrote:
>>> On 2017-10-09, allan gottlieb  wrote:
>>>
 This is a know bug see https://bugs.gentoo.org/633790
>>>
>>> Yep, that's it.  Yet when you search for roundingflags or
>>> shapedtextflags in Gentoo's bugzilla, it finds nothing.  Has the
>>> search feature in Bugzilla ever worked?
>>
>> It's pretty limited.
>
> You're being too kind.  It's broken.  According to the bugzilla web
> page, the search includes the summary/description (as one might
> expect), but it doesn't actually _do_ that.
>

Well, it successfully searches for substrings.

>> You might notice developers renaming bugs -
>> this is why. They usually include the full package name and version
>> in their rename, as well as the exact text from the last or most
>> important error encountered.
>
> Why do people still use bugzilla??
>
> I've used MantisBT a lot over the past few years, and it seems like it
> works much better than bugzilla in many ways. It even has a search
> that works!  Even Jira was better than bugzilla, and I never liked
> Jira much.
>
> Of course switching from one bug tracking system to another is a
> pretty big undertaking...
>

I worked with a project that used Mantis and had a good experience
with it. At this point I'm not sure it would be possible to get people
to switch.

There are a few migration scripts:
http://www.mantisbt.org/wiki/doku.php/mantisbt:faq.

R0b0t1.

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-09, R0b0t1  wrote:
> On Monday, October 9, 2017, Grant Edwards  wrote:
>> On 2017-10-09, allan gottlieb  wrote:
>>
>>> This is a know bug see https://bugs.gentoo.org/633790
>>
>> Yep, that's it.  Yet when you search for roundingflags or
>> shapedtextflags in Gentoo's bugzilla, it finds nothing.  Has the
>> search feature in Bugzilla ever worked?
>
> It's pretty limited.

You're being too kind.  It's broken.  According to the bugzilla web
page, the search includes the summary/description (as one might
expect), but it doesn't actually _do_ that.

> You might notice developers renaming bugs -
> this is why. They usually include the full package name and version
> in their rename, as well as the exact text from the last or most
> important error encountered.

Why do people still use bugzilla??

I've used MantisBT a lot over the past few years, and it seems like it
works much better than bugzilla in many ways. It even has a search
that works!  Even Jira was better than bugzilla, and I never liked
Jira much.

Of course switching from one bug tracking system to another is a
pretty big undertaking...

--
Grant

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-08, Mick  wrote:

> Your compiler is barfing at something, but I'm no coder to know what this 
> might be.  In a Gentoo context, I'd start by checking you have installed and 
> switched to sys-devel/gcc-5.4.0-r3 which is the latest stable version and at 
> least here compiled and installed firefox-52.4.0 on 4 PCs without a problem.

It turns out that over the past week or so, there have been several
_different_ firefox ebuilds released.  One of them was broken:

  Version 52.4.0 (Oct 3) was OK.

  Version 52.4.0 (Oct 7) was broken.

  Version 52.4.0 (Oct 9) is OK.

You (and I) had successfully installed the Oct 3 version of 52.4.0,
but when I tried to install the Oct 7 version of 52.4.0, it failed.
The Oct 9 version is supposed to be fixed. I don't really see how you
can repeatedly release new versions of something without changing the
version number, but maybe that's just me...

-- 
Grant Edwards   grant.b.edwardsYow! Being a BALD HERO
  at   is almost as FESTIVE as a
  gmail.comTATTOOED KNOCKWURST.

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-09, allan gottlieb  wrote:

> This is a know bug see https://bugs.gentoo.org/633790

Yep, that's it.  Yet when you search for roundingflags or
shapedtextflags in Gentoo's bugzilla, it finds nothing.  Has the
search feature in Bugzilla ever worked?

-- 
Grant Edwards   grant.b.edwardsYow! Four thousand
  at   different MAGNATES, MOGULS
  gmail.com& NABOBS are romping in my
   gothic solarium!!

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[allan gottlieb]

On Mon, Oct 09 2017, Grant Edwards wrote:

> On 2017-10-09, Grant Edwards  wrote:
>> On 2017-10-09, R0b0t1  wrote:
>>
>>> In this case the namespace of the missing declaration is inside
>>> Mozilla's, e.g. it is part of Firefox or a closely bundled library.
>>
>> Yep, after a bit more research, that was my conclusion.
>>
>> The chromium build finished happily, so I've just started another
>> firefox build with MAKEOPTS=-j1.  
>
> Same error.  But at least it's at the end of the build log now where
> it's easy to find. :)
>
> I guess I'll wait for the next firefox ESR update and see if that one
> builds.

This is a know bug see https://bugs.gentoo.org/633790

allan

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-09, Grant Edwards  wrote:
> On 2017-10-09, R0b0t1  wrote:
>
>> In this case the namespace of the missing declaration is inside
>> Mozilla's, e.g. it is part of Firefox or a closely bundled library.
>
> Yep, after a bit more research, that was my conclusion.
>
> The chromium build finished happily, so I've just started another
> firefox build with MAKEOPTS=-j1.  

Same error.  But at least it's at the end of the build log now where
it's easy to find. :)

I guess I'll wait for the next firefox ESR update and see if that one
builds.

-- 
Grant

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-09, R0b0t1  wrote:

> In this case the namespace of the missing declaration is inside
> Mozilla's, e.g. it is part of Firefox or a closely bundled library.

Yep, after a bit more research, that was my conclusion.

The chromium build finished happily, so I've just started another
firefox build with MAKEOPTS=-j1.  

The USE flag settings for firefox appear to be the same as my other
systems where it builds without error.

Weird.

-- 
Grant

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[R0b0t1]

On Sun, Oct 8, 2017 at 4:53 PM, Grant Edwards  wrote:
> On 2017-10-08, R0b0t1  wrote:
>
>> Usually what happens is it will be corrupted in RAM after being
>> verified on disk, and faulty results will be saved to disk from RAM. A
>> user on the forums recently had this issue compiling dev-lang/vala,
>> and I have had related issues.
>
> I've had failing RAM corrupt files and cause compile failures (and
> various other odd problems). But, the exact symptoms tend to be pretty
> random.  The chances are infinitesmal that a HW problem would corrupt
> the download (or the compile itself) in an identical manner a second
> time.
>

Right, redownloading or rerunning the compilation usually fixes such
issues. At the same time, I have seen people hit bad areas of RAM
repeatedly and have it look like other errors.

>> As for what the error means: definitions are missing, which from an
>> end-user perspective is not really a fixable issue.
>
> Sometimes there are external library version/use-flag requirements
> that don't make it into an ebuild file correctly.  But, all the other
> cases I've run into like that yielded plenty of Google hits on the
> error messages.
>

In this case the namespace of the missing declaration is inside
Mozilla's, e.g. it is part of Firefox or a closely bundled library.

Cheers,
R0b0t1

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-08, R0b0t1  wrote:

> Usually what happens is it will be corrupted in RAM after being
> verified on disk, and faulty results will be saved to disk from RAM. A
> user on the forums recently had this issue compiling dev-lang/vala,
> and I have had related issues.

I've had failing RAM corrupt files and cause compile failures (and 
various other odd problems). But, the exact symptoms tend to be pretty
random.  The chances are infinitesmal that a HW problem would corrupt
the download (or the compile itself) in an identical manner a second
time.

> As for what the error means: definitions are missing, which from an
> end-user perspective is not really a fixable issue.

Sometimes there are external library version/use-flag requirements
that don't make it into an ebuild file correctly.  But, all the other
cases I've run into like that yielded plenty of Google hits on the
error messages.

> I would rerun the compilation with -j1 if you have not already done
> so.

I'm going to try that as soon as chromium finishes building.

> If other people can build the package then portage may be munging the
> files in some way, but these issues are hard to diagnose.

-- 
Grant

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[R0b0t1]

On Sun, Oct 8, 2017 at 1:54 PM, Grant Edwards  wrote:
> On 2017-10-08, Mick  wrote:
>> This won't harm, although I would expect portage would complain and
>> not run the emerge if downloads were corrupted somehow.
>
> True, but I couldn't think of anything else to try.  I'm building
> chromium now -- it may be time to give up on firefox.  It's been
> bahaving badly on several of my systems for a while now (burning 100%
> cpu and using up huge amounts of RAM for minutes at a time while
> apparently doing nothing).
>

Usually what happens is it will be corrupted in RAM after being
verified on disk, and faulty results will be saved to disk from RAM. A
user on the forums recently had this issue compiling dev-lang/vala,
and I have had related issues.

As for what the error means: definitions are missing, which from an
end-user perspective is not really a fixable issue. I would rerun the
compilation with -j1 if you have not already done so. If other people
can build the package then portage may be munging the files in some
way, but these issues are hard to diagnose.

Cheers,
 R0b0t1

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-08, Mick  wrote:
> On Sunday, 8 October 2017 18:02:43 BST Grant Edwards wrote:
>
>> I was afraid it might be failing RAM, but a second attempt failed in
>> exactly the same way.  I guess I'll delete the ebuild files and the
>> source tarball to force a download and then try again.

Same error.

> This won't harm, although I would expect portage would complain and
> not run the emerge if downloads were corrupted somehow.

True, but I couldn't think of anything else to try.  I'm building
chromium now -- it may be time to give up on firefox.  It's been
bahaving badly on several of my systems for a while now (burning 100%
cpu and using up huge amounts of RAM for minutes at a time while
apparently doing nothing).

-- 
Grant

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Mick]

On Sunday, 8 October 2017 18:02:43 BST Grant Edwards wrote:

> I was afraid it might be failing RAM, but a second attempt failed in
> exactly the same way.  I guess I'll delete the ebuild files and the
> source tarball to force a download and then try again.

This won't harm, although I would expect portage would complain and not run 
the emerge if downloads were corrupted somehow.
-- 
Regards,
Mick

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

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-08, Mick  wrote:
> On Sunday, 8 October 2017 03:51:41 BST Grant Edwards wrote:
>> When I did my usual update today firefox 52.4.0 failed to build.
>> There are thousands of compiler warnings in the build log, but the
>> only thing I can find that looks like an error is this:

[...]

>> Google provides zero hits for any of those three errors.

> Your compiler is barfing at something, but I'm no coder to know what
> this might be.

Yes, thanks, those are g++ compiler error messages.  I could track
down and fix the problem in the source code, but since it's a "stable"
system, and firefox builds fine on other systems, I should have to do
that.

> In a Gentoo context, I'd start by checking you have installed and 
> switched to sys-devel/gcc-5.4.0-r3

Yep, I'm using gcc-5.4.0-r3.  There were 20+ other packages that got
built in that same upgrade, and they all went fine.

> which is the latest stable version and at least here compiled and
> installed firefox-52.4.0 on 4 PCs without a problem.

As have I.

I was afraid it might be failing RAM, but a second attempt failed in
exactly the same way.  I guess I'll delete the ebuild files and the
source tarball to force a download and then try again.

-- 
Grant

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

[Miroslav Rovis]

On 161024-22:27+0200, Alarig Le Lay wrote:
> On Mon Oct 24 15:49:09 2016, Rich Freeman wrote:
> > Why not just share everything via bind mounts in this case?  I'd think
> > that would have less overhead than rsync/http and then you're not
> > storing files twice.
> 
> Because I have several host boxes and I build the packages on only one.

I used to have 3 (even 4) same-hardware machines (well same MBO really)
in daily use, and the local mirror is not an overkill long run. And if
you look for security, then also Air-Gapping and cloning is a perfect
solution, because you get a clean clone for online with an Air-Gapped
that does not see online...

Some peple like rather btrfs ...

I had written a lot about Air-Gapped and cloning on the Forums, but
maybe moderators would call it "blogging" if I gave you the link.

btrfs I never used OTOH.

-- 
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature

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

[Alarig Le Lay]

On Mon Oct 24 15:49:09 2016, Rich Freeman wrote:
> Why not just share everything via bind mounts in this case?  I'd think
> that would have less overhead than rsync/http and then you're not
> storing files twice.

Because I have several host boxes and I build the packages on only one.

-- 
alarig


signature.asc
Description: Digital signature

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

[Rich Freeman]

On Mon, Oct 24, 2016 at 2:02 PM, Alarig Le Lay  wrote:
>
> I use a similar setup for LXC containers running over a gentoo box,
> except that my box is setted up to publish the binary packets on a
> specified directory that is accessible via HTTP. My LXCs take the binary
> packages from this HTTP location and do their normal stuff afterward.
> The host box is also a local rsync mirror.
>

Why not just share everything via bind mounts in this case?  I'd think
that would have less overhead than rsync/http and then you're not
storing files twice.

-- 
Rich

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

[Alarig Le Lay]

On Mon Oct 24 10:44:24 2016, Jorge Almeida wrote:
> My use case is basic: 2 home computers, I do emerge et. al. on the
> faster one and produce binary packages to be used on the other one,
> which doesn't even need distfiles, just portage tree plus binary
> packages.  I copy stuff between boxes with rsync via ssh. Simple
> enough and it seems to be working fine.

I use a similar setup for LXC containers running over a gentoo box,
except that my box is setted up to publish the binary packets on a
specified directory that is accessible via HTTP. My LXCs take the binary
packages from this HTTP location and do their normal stuff afterward.
The host box is also a local rsync mirror.

-- 
alarig


signature.asc
Description: Digital signature