Re: [gentoo-user] hardware - memory problem

在 2020/12/17 上午7:12, the...@sys-concept.com 写道: AMD FX(tm)-8150 Eight-Core Processor Have you test the 64bit install image ? We told you several days ago that your cpu (AMD FX[tm]-8150 Eight-Core Processor) is a 64 bit cpu. You'd better reinstall a 64bit system. Using a 32 bit system nowadays

Re: [gentoo-user] sci-libs/{amd,camd}-2.4.6/ doc wierdness

On 12/16/20 5:16 PM, k...@aspodata.se wrote: It will probably, cannot test just now, rust is compiling I'm sorry for your loss. I opened https://bugs.gentoo.org/760408 to track this issue, but we will probably hack around it in the ebuild for now. Our SuiteSparse ebuilds are far

[gentoo-user] Re: hardware - memory problem

On 2020-12-16, Grant Edwards wrote: >> Hm..., did I use wrong stage? >> >> stage3-i686-20201116T214503Z.tar.xz >> >> AMD FX(tm)-8150 Eight-Core Processor > > Yes, that is the wrong stage3. It's for 32-bit processors. You want a > 64-bit amd64 one. You're also running a 32-bit kernel instead of

[gentoo-user] Re: hardware - memory problem

On 2020-12-16, the...@sys-concept.com wrote: > On 12/16/2020 03:51 PM, antlists wrote: >> Or is this a 32-bit system WITHOUT extended memory support? >> >> I don't properly understand it, but with a 32-bit system the kernel uses >> 1GB of memory and user-space uses the other 3GB. Extended memory

Re: [gentoo-user] hardware - memory problem

On Wed, Dec 16, 2020 at 3:14 PM wrote: > On 12/16/2020 04:01 PM, Mark Knecht wrote: > >> When I loot at "htop" it only shows: > >> Mem:155M/3.21G > > You show all 16GB but as others have stated you are likely running the > > wrong kernel. > > > > uname -a > > > uname -a > > Linux 7_old

Re: [gentoo-user] hardware - memory problem

On Wed, Dec 16, 2020 at 4:14 PM wrote: > > On 12/16/2020 04:01 PM, Mark Knecht wrote: > >> When I loot at "htop" it only shows: > >> Mem:155M/3.21G > > You show all 16GB but as others have stated you are likely running the > > wrong kernel. > > > > uname -a > > > uname -a > > Linux 7_old

Re: [gentoo-user] hardware - memory problem

On 12/16/2020 04:01 PM, Mark Knecht wrote: >> When I loot at "htop" it only shows: >> Mem:155M/3.21G > You show all 16GB but as others have stated you are likely running the > wrong kernel. > > uname -a > uname -a Linux 7_old 5.4.80-gentoo-r1 #2 SMP Tue Dec 15 00:21:33 MST 2020 i686 AMD

Re: [gentoo-user] hardware - memory problem

On 12/16/2020 03:51 PM, antlists wrote: > Or is this a 32-bit system WITHOUT extended memory support? > > I don't properly understand it, but with a 32-bit system the kernel uses > 1GB of memory and user-space uses the other 3GB. Extended memory support > means each process can have its own 3GB

Re: [gentoo-user] hardware - memory problem

On Wed, Dec 16, 2020 at 3:46 PM wrote: > lshw -C memory > *-memory >description: System Memory >physical id: 29 >slot: System board or motherboard >size: 16GiB > *-bank:0 > description: DIMM 1333 MHz (0.8 ns) > physical id: 0 >

Re: [gentoo-user] hardware - memory problem

On 16/12/2020 22:34, Mark Knecht wrote: On Wed, Dec 16, 2020 at 3:29 PM Mark Knecht > wrote: > > > > On Wed, Dec 16, 2020 at 3:22 PM > wrote: >> >> I run Memtest86 on my old box and it completed 1pass without any errors. >>

Re: [gentoo-user] hardware - memory problem

On Wed, Dec 16, 2020 at 2:22 PM wrote: > I run Memtest86 on my old box and it completed 1pass without any errors. > Memtest86 reports 16G memory > > When I boot Gentoo it shows only 3282Mb > free -m > totalusedfree shared buff/cache > available > Mem:

Re: [gentoo-user] hardware - memory problem

On 12/16/2020 03:34 PM, Mark Knecht wrote: > On Wed, Dec 16, 2020 at 3:29 PM Mark Knecht wrote: >> >> >> >> On Wed, Dec 16, 2020 at 3:22 PM wrote: >>> >>> I run Memtest86 on my old box and it completed 1pass without any errors. >>> Memtest86 reports 16G memory >>> >>> When I boot Gentoo it shows

Re: [gentoo-user] hardware - memory problem

On Wed, Dec 16, 2020 at 3:29 PM Mark Knecht wrote: > > > > On Wed, Dec 16, 2020 at 3:22 PM wrote: >> >> I run Memtest86 on my old box and it completed 1pass without any errors. >> Memtest86 reports 16G memory >> >> When I boot Gentoo it shows only 3282Mb >> free -m >> total

Re: [gentoo-user] hardware - memory problem

On Wed, Dec 16, 2020 at 3:22 PM wrote: > I run Memtest86 on my old box and it completed 1pass without any errors. > Memtest86 reports 16G memory > > When I boot Gentoo it shows only 3282Mb > free -m > totalusedfree shared buff/cache > available > Mem:

[gentoo-user] hardware - memory problem

I run Memtest86 on my old box and it completed 1pass without any errors. Memtest86 reports 16G memory When I boot Gentoo it shows only 3282Mb free -m totalusedfree shared buff/cache available Mem: 3282 1252475 7 680

Re: [gentoo-user] sci-libs/{amd,camd}-2.4.6/ doc wierdness

Michael: > On 12/16/20 1:17 PM, Michael Orlitzky wrote: > > On 12/16/20 12:30 PM, k...@aspodata.se wrote: > >> Both sci-libs/{amd,camd}-2.4.6 gives this error in their build log: > >> > >>! Package inputenc Error: Unicode character ^^H (U+0008) > >>(inputenc)not set up for

Re: [gentoo-user] syslog-ng: filter plugin NOT not found ????

23 is the hard coded constant for local7. They are identical. facility(23) and facility(local7) mean the exact same thing. On 12/16/2020 10:30 AM, David Haller wrote: Hello, On Wed, 16 Dec 2020, Todd Goodman wrote: I think you need a semi-colon inside and after the right curly brace ('}')

Re: [gentoo-user] syslog-ng: filter plugin NOT not found ????

Well, I'm starting to make progress. But something isn't right. I found out the plugin error was due to the fact that despite syslog-ng.com showing the reversal as NOT, the actual statement is not (all lower case vs all upper case). So that means that syslog-ng loads just fine. But I can't get

Re: [gentoo-user] sci-electronics/ngspice-27-r1 missing tcl

On Wed, 16 Dec 2020 18:30:47 +0100 (CET), k...@aspodata.se wrote: > What can I do to make ./configure below use the suggested option ? > > sci-electronics/ngspice-27-r1's build log contains: > > checking for tclConfig.sh... > can't find Tcl configuration script "tclConfig.sh" > Should you

Re: [gentoo-user] sci-libs/{amd,camd}-2.4.6/ doc wierdness

On 12/16/20 1:17 PM, Michael Orlitzky wrote: On 12/16/20 12:30 PM, k...@aspodata.se wrote: Both sci-libs/{amd,camd}-2.4.6 gives this error in their build log: ! Package inputenc Error: Unicode character ^^H (U+0008) (inputenc)not set up for use with LaTeX. I can

Re: [gentoo-user] sci-libs/{amd,camd}-2.4.6/ doc wierdness

On 12/16/20 12:30 PM, k...@aspodata.se wrote: Both sci-libs/{amd,camd}-2.4.6 gives this error in their build log: ! Package inputenc Error: Unicode character ^^H (U+0008) (inputenc)not set up for use with LaTeX. I can reproduce this... I'll take a look.

Re: [gentoo-user] syslog-ng: filter plugin NOT not found ????

Hello, On Wed, 16 Dec 2020, Todd Goodman wrote: >I think you need a semi-colon inside and after the right curly brace ('}') > >You right braces are parentheses and not right curly braces too (maybe a cut >and paste issue?) > >FWIW, the following is what I use to separate my mail logs out and it

[gentoo-user] sci-libs/{amd,camd}-2.4.6/ doc wierdness

Both sci-libs/{amd,camd}-2.4.6 gives this error in their build log: ! Package inputenc Error: Unicode character ^^H (U+0008) (inputenc)not set up for use with LaTeX. And sure enough, somehow theese files begins with backspace. The line should be "\begin{verbatim}". My guess

[gentoo-user] sci-electronics/ngspice-27-r1 missing tcl

What can I do to make ./configure below use the suggested option ? sci-electronics/ngspice-27-r1's build log contains: checking for tclConfig.sh... can't find Tcl configuration script "tclConfig.sh" Should you add --with-tcl=/usr/lib64 to ./configure arguments? I have

Re: [gentoo-user] Recommended location of the Gentoo ebuild repository

On Wed, Dec 16, 2020 at 8:26 AM antlists wrote: > > On 16/12/2020 14:58, Mark Knecht wrote: > > > > > > On Wed, Dec 16, 2020 at 7:46 AM gevisz > > wrote: > > > > > Nevertheless, the explanation why /var/db/repos/gentoo is better than > > > /usr/portage is still

Re: [gentoo-user] Recommended location of the Gentoo ebuild repository

ср, 16 дек. 2020 г. в 16:55, Rich Freeman : > > On Wed, Dec 16, 2020 at 9:45 AM gevisz wrote: > > > > Nevertheless, the explanation why /var/db/repos/gentoo is better than > > /usr/portage is still welcomed. :) > > > > There is a lengthy discussion on gentoo-dev on this, and my personal > first

Re: [gentoo-user] Re: Recommended location of the Gentoo ebuild repository

Nikos Chantziaras wrote: > On 16/12/2020 13:51, gevisz wrote: >> How would you comment the following quote from Gentoo Handbook >> "In most situations, /usr/ is to be kept big: not only will it contain >>    the majority of applications, it typically also hosts the Gentoo >> ebuild >>   

Re: [gentoo-user] Recommended location of the Gentoo ebuild repository

On Wed, Dec 16, 2020 at 10:25 AM antlists wrote: > > Here we are storing the data (source files) used to build a gentoo > system. So while it may be a bit tenuous (I find Rich's argument for > "cache" more compelling), I don't think the argument for calling this a > database that strange -

Re: [gentoo-user] Recommended location of the Gentoo ebuild repository

On 16/12/2020 14:55, Rich Freeman wrote: Now, where exactly in /var it goes is more a matter of debate. /var/db is not specified in FHS, but it is used by FreeBSD which I think was one of the selling points. Personally I stick it in /var/cache as (IMO) it just contains a local copy of a

Re: [gentoo-user] Recommended location of the Gentoo ebuild repository

On 16/12/2020 14:58, Mark Knecht wrote: On Wed, Dec 16, 2020 at 7:46 AM gevisz > wrote: > Nevertheless, the explanation why /var/db/repos/gentoo is better than > /usr/portage is still welcomed. :) Community opinion mostly:

[gentoo-user] Re: Recommended location of the Gentoo ebuild repository

On 16/12/2020 13:51, gevisz wrote: How would you comment the following quote from Gentoo Handbook "In most situations, /usr/ is to be kept big: not only will it contain the majority of applications, it typically also hosts the Gentoo ebuild repository (by default located at

Re: [gentoo-user] Recommended location of the Gentoo ebuild repository

On Wed, Dec 16, 2020 at 7:46 AM gevisz wrote: > Nevertheless, the explanation why /var/db/repos/gentoo is better than > /usr/portage is still welcomed. :) Community opinion mostly: https://serverfault.com/questions/384342/what-are-the-best-practices-of-the-usr-var-and-etc-folders#384345 In

Re: [gentoo-user] Recommended location of the Gentoo ebuild repository

On Wed, Dec 16, 2020 at 9:45 AM gevisz wrote: > > Nevertheless, the explanation why /var/db/repos/gentoo is better than > /usr/portage is still welcomed. :) > There is a lengthy discussion on gentoo-dev on this, and my personal first choice didn't win. :) There is little dispute that /var

Re: [gentoo-user] Recommended location of the Gentoo ebuild repository

> On Wed, 16 Dec 2020 at 21:52, gevisz wrote: > > > > How would you comment the following quote from Gentoo Handbook > > "In most situations, /usr/ is to be kept big: not only will it contain > > the majority of applications, it typically also hosts the Gentoo ebuild > > repository (by

Re: [gentoo-user] syslog-ng: filter plugin NOT not found ????

I think you need a semi-colon inside and after the right curly brace ('}') You right braces are parentheses and not right curly braces too (maybe a cut and paste issue?) FWIW, the following is what I use to separate my mail logs out and it works: destination messages {

Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision

Miles Malone wrote: > Personally I just like to see what I'm getting myself into before I > start doing an upgrade or recompile on all of chromium, firefox, > qt-webkit, gtk-webkit, qt-webengine, libreoffice, and electron all at > once :p > To quote the meme, this little manouver's going to take

Re: [gentoo-user] Recommended location of the Gentoo ebuild repository

It was historically in /usr/portage, it's now in /var/db/repos/gentoo. The handbook is apparently out of date on this. If you've got the time I'm sure the handbook maintainers would appreciate a patch or a bug On Wed, 16 Dec 2020 at 21:52, gevisz wrote: > > How would you comment the following

[gentoo-user] Recommended location of the Gentoo ebuild repository

How would you comment the following quote from Gentoo Handbook "In most situations, /usr/ is to be kept big: not only will it contain the majority of applications, it typically also hosts the Gentoo ebuild repository (by default located at /var/db/repos/gentoo) which already takes around 650

Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision

Personally I just like to see what I'm getting myself into before I start doing an upgrade or recompile on all of chromium, firefox, qt-webkit, gtk-webkit, qt-webengine, libreoffice, and electron all at once :p To quote the meme, this little manouver's going to take us 51 years On Wed, 16 Dec

Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision

If it's wanting to downgrade something you definitely wouldnt want downgraded is one, but feel free to omit the "a" and do the above anyway On Wed, 16 Dec 2020 at 21:06, n952162 wrote: > > On 12/16/20 11:34 AM, Miles Malone wrote: > > What's happening when you do emerge -avuDN --with-bdeps=y > >

Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision

On 12/16/20 11:34 AM, Miles Malone wrote: What's happening when you do emerge -avuDN --with-bdeps=y --backtrack=100 @world ? Giving portage the flexibility to solve it with some extra backtracking and increasing the scope to world might fix it, if not then we can revisit it? I don't remember

Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision

On Wed, 16 Dec 2020 at 11:34, Miles Malone wrote: > What's happening when you do emerge -avuDN --with-bdeps=y > --backtrack=100 @world ? Giving portage the flexibility to solve it > with some extra backtracking and increasing the scope to world might > fix it, if not then we can revisit it? You

Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision

在 2020/12/16 下午6:24, n952162 写道: In an update with several slot collisions (see attachment), I'm zero-ing in on the simplest, where a package is to be replaced by the same package, but with different PYTHON_TARGETS (at least, that's how I interpret it). Is there a way to force the

Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision

What's happening when you do emerge -avuDN --with-bdeps=y --backtrack=100 @world ? Giving portage the flexibility to solve it with some extra backtracking and increasing the scope to world might fix it, if not then we can revisit it? On Wed, 16 Dec 2020 at 20:24, n952162 wrote: > > In an update

[gentoo-user] override PYTHON_TARGETS to avoid a slot collision

In an update with several slot collisions (see attachment),  I'm zero-ing in on the simplest, where a package is to be replaced by the same package, but with different PYTHON_TARGETS (at least, that's how I interpret it). Is there a way to force the PYTHON_TARGETS of the dependency? Slot