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

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

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

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

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

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

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

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

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

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

[gentoo-user] Re: Emerge load again

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[gentoo-user] Re: emerge times blown out

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

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

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

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.

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[gentoo-user] Re: Emerge and binary packages

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

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

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.

[gentoo-user] Re: Emerge and binary packages

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

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

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

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

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,

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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, >

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

Î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

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

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,

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

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

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

Î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:

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

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)

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

Î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": [ >

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

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",

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

Î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 ?

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

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

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

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

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

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

[gentoo-user] Re: emerge --info

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?

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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/ > > > >

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

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/ > >

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

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/ >

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

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

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

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

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

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

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

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

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

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

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

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.  

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

  1   2   3   4   5   6   >