On 2024-09-03, Grant Edwards wrote:
> On 2024-09-03, Matthew Brooks wrote:
>
>> It might be worth seeing what a full update of world, with the
>> --emptytree flag says (though without actually doing the
>> rebuild). Sometimes including that will notice inconsistencies that
>> a regular emerge doe
On 2024-09-03, Matthew Brooks wrote:
> It might be worth seeing what a full update of world, with the
> --emptytree flag says (though without actually doing the
> rebuild). Sometimes including that will notice inconsistencies that
> a regular emerge doesn't spot.
I don't see anything. It still
On 2024-09-03, Grant Edwards wrote:
> On 2024-09-03, Matthew Brooks wrote:
>
>> While I'm not familiar enough with those packages to know for
>> certain, it sounds like they're probably *build* dependencies for
>> something, [...]
>
> I don't think so. Nothing else is getting built.
>
> I can alt
On 2024-09-03, Matthew Brooks wrote:
> It might be worth seeing what a full update of world, with the
> --emptytree flag says (though without actually doing the
> rebuild). Sometimes including that will notice inconsistencies that
> a regular emerge doesn't spot.
Thanks, I'll try that next time
On 2024-09-03, Matthew Brooks wrote:
> While I'm not familiar enough with those packages to know for
> certain, it sounds like they're probably *build* dependencies for
> something, but not actual *runtime* dependencies, and so depclean
> prunes them, and then whenever the package that needs them
Actually, looking more closely at the emerge man pages, it says that
--with-bdeps is already automatically supplied for depclean, so that's probably
not the issue after all. My apologies.
It might be worth seeing what a full update of world, with the --emptytree flag
says (though without actual
While I'm not familiar enough with those packages to know for certain, it
sounds like they're probably *build* dependencies for something, but not actual
*runtime* dependencies, and so depclean prunes them, and then whenever the
package that needs them gets built again they get pulled in again.
On 2024-09-03, Grant Edwards wrote:
> For the past 4 days or so, every time I do a sync and then
> 'emerge -auvND world', portage installs the following:
>
> qttools
> qtbase
> qttranslations
> xcb-util-cursor
>
> Afterwards, when I do 'emerge --depclean', it uninstalls them.
>
> Any ideas
On 2024-09-02, Michael wrote:
> On Monday, 2 September 2024 07:59:20 BST Wols Lists wrote:
>> On 02/09/2024 06:11, Dale wrote:
>> > If you have a laptop where heat is a issue, you may want to do things
>> > different but if you can, that will give you the most stable system for
>> > updates.
>>
>
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 i
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
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
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 pr
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 t
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'
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 def
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
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 i
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 san
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 exp
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.
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 culp
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
>>
> How is it compared to PyPy3?
>
> I didn’t find pypy any faster than 3.10.
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.
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 Ia
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:
>
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 --sy
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:
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'...
> >
> > *
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 ke
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
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 change
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.
--
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
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
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
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
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
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.
>
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
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-colo
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
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
>
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
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 col
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 backg
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 s
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
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 specifi
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.
Th
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::gen
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 sy
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(
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.
Î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 n
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
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_regis
Î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
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-
Î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/readl
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",
Î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 ?
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 ou
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.
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/pack
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.
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
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 -f
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 ex
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.
>
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
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 th
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 b
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.
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
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_lib
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.
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
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 fro
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 wha
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 woul
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.
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 involv
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 adva
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.
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)
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 c
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
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
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 j
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
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 roundi
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 n
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 install
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
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, tha
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 finishe
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
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,
1 - 100 of 521 matches
Mail list logo