Re: [gentoo-user] hardware - memory problem

[bobwxc]

在 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 is not a good choice.

Be patient and careful.
Install and config a new gentoo may very painful at start, but when you 
did it, you will happy for a long time.

;-)

--
bobwxc




OpenPGP_signature
Description: OpenPGP digital signature

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

[Michael Orlitzky]

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 behind the upstream versions 
and had their autotools build system patched in, at a time when the 
upstream build system was junk.


Nowadays upstream is using CMake, so it makes more sense to upgrade and 
switch to CMake than it does to try to fix the evolutionary-dead-end 
autotools patches.

[gentoo-user] Re: hardware - memory problem

[Grant Edwards]

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 a
> 64-bit one.
>
> If I were you, I'd start over from scratch.

Follow the manual _carefully_:

https://wiki.gentoo.org/wiki/Handbook:AMD64

 * You want to do a 64-bit, "amd64" installation. Do _not_ use
   anything that says "i686" in the filename.

 * You need to read and understand every manual section before you do
   that section.

 * I highly recommend cuting/pasting the example commands from the
   manual into the terminal where you are doing the install (instead
   of typing them manually).

 * Make sure you start out booting some sort of _64_bit_ live ISO to do
   the install (either the Gentoo minimal install or systemrescuecd or
   whatever).

 * Verify the signatures of the downloaded files.

[gentoo-user] Re: hardware - memory problem

[Grant Edwards]

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 support
>> means each process can have its own 3GB space which enables you to use
>> all available memory, but without it I think the entire system is stuck
>> in the first 4GB.
>> 
>> Cheers,
>> Wol
>
> 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 a
64-bit one.

If I were you, I'd start over from scratch.

--
Grant

Re: [gentoo-user] hardware - memory problem

[Manuel McLure]

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 5.4.80-gentoo-r1 #2 SMP Tue Dec 15 00:21:33 MST 2020 i686
> AMD FX(tm)-8150 Eight-Core Processor AuthenticAMD GNU/Linux
>
>
i686 is a 32-bit kernel. Where it says "i686" it should instead say
"x86_64". For example, on my Gentoo server:

Linux legend 5.4.80-gentoo-r1-x86_64 #1 SMP Wed Dec 2 10:51:23 PST 2020
x86_64 Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz GenuineIntel GNU/Linux

-- 
Manuel A. McLure WW1FA  
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.   -- H.P. Lovecraft

Re: [gentoo-user] hardware - memory problem

[Mark Knecht]

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 5.4.80-gentoo-r1 #2 SMP Tue Dec 15 00:21:33 MST 2020 i686
> AMD FX(tm)-8150 Eight-Core Processor AuthenticAMD GNU/Linux

I don't know. You've done something wrong.

Do you have a /proc/config.gz file? zcat it and look for settings of the
running kernel that indicate limiting memory or something.

Sorry. I'm not able to help you much more at this distance.

- Mark

Re: [gentoo-user] hardware - memory problem

[thelma]

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 FX(tm)-8150 Eight-Core Processor AuthenticAMD GNU/Linux

Re: [gentoo-user] hardware - memory problem

[thelma]

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 space which enables you to use
> all available memory, but without it I think the entire system is stuck
> in the first 4GB.
> 
> Cheers,
> Wol

Hm..., did I use wrong stage?

stage3-i686-20201116T214503Z.tar.xz
on:
AMD FX(tm)-8150 Eight-Core Processor

Re: [gentoo-user] hardware - memory problem

[Mark Knecht]

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
>   slot: A0
>   size: 4GiB
>   width: 64 bits
>   clock: 1333MHz (0.8ns)
>  *-bank:1
>   description: DIMM 1333 MHz (0.8 ns)
>   physical id: 1
>   slot: A1
>   size: 4GiB
>   width: 64 bits
>   clock: 1333MHz (0.8ns)
>  *-bank:2
>   description: DIMM 1333 MHz (0.8 ns)
>   physical id: 2
>   slot: A2
>   size: 4GiB
>   width: 64 bits
>   clock: 1333MHz (0.8ns)
>  *-bank:3
>   description: DIMM 1333 MHz (0.8 ns)
>   physical id: 3
>   slot: A3
>   size: 4GiB
>   width: 64 bits
>   clock: 1333MHz (0.8ns)
>
>
> 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

Re: [gentoo-user] hardware - memory problem

[antlists]

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.
 >> Memtest86 reports 16G memory
 >>
 >> When I boot Gentoo it shows only 3282Mb
 >> free -m
 >>               total        used        free      shared  buff/cache
 >> available
 >> Mem:           3282         125        2475           7         680
 >>   3033
 >>
 >> Is it a motherboard? How to test it?
 >>
 >
 > Start with
 >
 > cat /proc/meminfo


Or lshw and look for the DIMM modules themselves


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 space which enables you to use 
all available memory, but without it I think the entire system is stuck 
in the first 4GB.


Cheers,
Wol

Re: [gentoo-user] hardware - memory problem

[Manuel McLure]

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:   3282 1252475   7 680
>   3033
>
> Is it a motherboard? How to test it?
>
>
Are you perhaps booting a 32-bit kernel? A 32 bit kernel is not going to
see all 16GB of RAM, only what fits in its 32-bit address space. You need a
64-bit kernel (or a 32-bit kernel with Physical Address Extensions enabled)
to be able to see all the RAM.
-- 
Manuel A. McLure WW1FA  
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.   -- H.P. Lovecraft

Re: [gentoo-user] hardware - memory problem

[thelma]

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 only 3282Mb
>>> free -m
>>>   totalusedfree  shared  buff/cache
>>> available
>>> Mem:   3282 1252475   7 680
>>>   3033
>>>
>>> Is it a motherboard? How to test it?
>>>
>>
>> Start with
>>
>> cat /proc/meminfo
> 
>>
> Or lshw and look for the DIMM modules themselves

cat /proc/meminfo
MemTotal:3360992 kB
MemFree: 2806556 kB
MemAvailable:3077952 kB
Buffers:   97156 kB
Cached:   262116 kB
SwapCached:0 kB
Active:   329656 kB
Inactive: 133864 kB
Active(anon): 104804 kB
Inactive(anon): 2964 kB
Active(file): 224852 kB
Inactive(file):   130900 kB
Unevictable:   0 kB
Mlocked:   0 kB
HighTotal:   2504328 kB
HighFree:2120028 kB
LowTotal: 856664 kB
LowFree:  686528 kB
SwapTotal:   8757244 kB
SwapFree:8757244 kB
Dirty:   292 kB
Writeback: 0 kB
AnonPages:104252 kB
Mapped:93812 kB
Shmem:  3516 kB
KReclaimable:  34340 kB
Slab:  56524 kB
SReclaimable:  34340 kB
SUnreclaim:22184 kB
KernelStack:2256 kB
PageTables: 2596 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit:10437740 kB
Committed_AS: 987564 kB
VmallocTotal: 122880 kB
VmallocUsed:4080 kB
VmallocChunk:  0 kB
Percpu: 1248 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   4096 kB
Hugetlb:   0 kB
DirectMap4k:   12280 kB
DirectMap4M:  32 kB


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
  slot: A0
  size: 4GiB
  width: 64 bits
  clock: 1333MHz (0.8ns)
 *-bank:1
  description: DIMM 1333 MHz (0.8 ns)
  physical id: 1
  slot: A1
  size: 4GiB
  width: 64 bits
  clock: 1333MHz (0.8ns)
 *-bank:2
  description: DIMM 1333 MHz (0.8 ns)
  physical id: 2
  slot: A2
  size: 4GiB
  width: 64 bits
  clock: 1333MHz (0.8ns)
 *-bank:3
  description: DIMM 1333 MHz (0.8 ns)
  physical id: 3
  slot: A3
  size: 4GiB
  width: 64 bits
  clock: 1333MHz (0.8ns)


When I loot at "htop" it only shows:
Mem:155M/3.21G

Re: [gentoo-user] hardware - memory problem

[Mark Knecht]

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
>>   totalusedfree  shared  buff/cache
>> available
>> Mem:   3282 1252475   7 680
>>   3033
>>
>> Is it a motherboard? How to test it?
>>
>
> Start with
>
> cat /proc/meminfo

>
Or lshw and look for the DIMM modules themselves

Re: [gentoo-user] hardware - memory problem

[Mark Knecht]

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:   3282 1252475   7 680
>   3033
>
> Is it a motherboard? How to test it?
>
>
Start with

cat /proc/meminfo

[gentoo-user] hardware - memory problem

[thelma]

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
  3033

Is it a motherboard? How to test it?

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

[karl]

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 use with LaTeX.
> >>
> > 
> > I can reproduce this... I'll take a look.
> It looks like the Makefile.am for the documentation was only tested with 
> bash.

  Yes, this part:
CAMD_UserGuide.pdf:
echo '\begin{verbatim}' > camd_h.tex
expand -8 $(top_srcdir)/Include/camd.h >> camd_h.tex
echo '\end{verbatim}' >> camd_h.tex
-ln -s $(srcdir)/*.{tex,bib} .
$(PDFLATEX) CAMD_UserGuide
$(BIBTEX)  CAMD_UserGuide
$(PDFLATEX) CAMD_UserGuide
$(PDFLATEX) CAMD_UserGuide

 Unfortunately, different echos handles excapes differently, see e.g.
https://helpmanual.io/man1/echo-posix/
 In /bin/sh (dash) echo always converts thoose excapes (a' la sysV),
 where bash needs -e to do it (a' la BSD).

 One could replace the echos with printf "%s\n" as in
$ printf "%s\n" '\begin' | od -a
000   \   b   e   g   i   n  nl

Note: echo '\e' is said to be undefined in dashs manual.

///

Also, the $(srcdir) seems defined as ".", and I get this useless link:
# ls -l
total 140
lrwxrwxrwx 1 portage portage13 Dec 16 16:58 '*.{tex,bib}' -> './*.{tex,bib}'

///

> Try e.g.,
> 
>CONFIG_SHELL=/bin/bash USE=doc emerge -v1 sci-libs/amd
> 
> If that works for you, I'll add it to the ebuilds.

It will probably, cannot test just now, rust is compiling

Regards,
/Karl Hammar

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

[Dan Egli]

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 ('}')

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 { file("/var/log/messages"); };
destination maillog { file("/var/log/maillog"); };

filter f_mail { facility(mail); };
filter f_messages { not facility(mail); };

log { source(src); filter(f_mail); destination(maillog); };
log { source(src); filter(f_messages); destination(messages); };

On 12/15/2020 10:44 PM, Dan Egli wrote:

Help me understand this, please?  I have ISC dhcpd configured to log to
syslog.local7 (since I don't see an option to force it into it's own log
file). So I went into my syslog-ng file and created two filters, just
like on the example page of syslog-ng.com:

filter dhcpmsgs { facility(23) );
filter non_dhcp { NOT filter(dhcpmsgs) )

Also, where's that '23' coming from? Shouldn't that be

 filter dhcpmsgs { facility(local7); };

HTH,
-dnh


--
Dan Egli
From my Test Server

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

[Dan Egli]

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 the dhcp output to where I want it. If I have the syslog 
facility in dhcpd turned on, or if I redirect the output to a file in 
systemd, then I get dhcpd messages in the file AND in the syslog itself 
(/var/log/messages). No matter what I try, the dhcpd output ALWAYS goes 
to syslog. I can get it to go to a separate file TOO, but not ONLY. 
Here's the entire syslog-ng.conf and the service file for dhcpd. 
Hopefully you guys can figure something out I missed:



(dhcpd4.service)
[Unit]
Description=DHCPv4 Server Daemon
Documentation=man:dhcpd(8) man:dhcpd.conf(5)
After=network.target
After=time-sync.target
After=network-online.target
Wants=network-online.target
StandardOut=null
StandardError=null

[Service]
ExecStart=/usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcp -group 
dhcp --no-pid


[Install]
WantedBy=multi-user.target


With everyhing going to null, you'd think that with the syslog statement 
in dhcpd.conf disabled, I'd get no log at all. But I still get the log 
in /var/log/messages. Here's syslog-ng.conf:

@version: 3.26

options {
    threaded(yes);
    chain_hostnames(no);
    stats_freq(43200);
    mark_freq(3600);
};
filter dhcpfilter { facility(local7); };
filter nondhcp { not filter(dhcpfilter); };
source src { system(); internal(); };
destination messages { file("/var/log/messages"); };
destination dhcplog { file("/var/log/dhcpd.log");  };
destination console_all { file("/dev/tty12"); };
log { source(src); filter(nondhcp); destination(messages);  };
log { source(src); destination(console_all); };
log { source(src); filter(dhcpfilter); destination(dhcplog);  };


And for what it's worth, here's my dhcpd.conf:
default-lease-time 3600;
max-lease-time 43200;

# Use this to enble / disable dynamic dns updates globally.
ddns-update-style interim;

authoritative;

# log-facility local7;


allow booting;

subnet 10.0.2.0 netmask 255.255.255.0 {
# no services at all!
}

subnet 192.168.10.0 netmask 255.255.255.0 {
    range 192.168.10.128 192.168.10.254;
    if exists user-class and option user-class = "iPXE" {
    filename "pxelinux.efi";
    } else {
    filename "pxelinux.0";
    }
    next-server 192.168.10.3;
    option domain-name-servers 192.168.10.2, 8.8.8.8;
    option domain-name "eglifamily.name";
    option routers 192.168.10.1;
}

host testbox-1 {
    hardware ethernet 08:00:27:D5:AA:3C;
    fixed-address 192.168.10.64;
    option host-name "testbox-1";
    ddns-hostname "testbox-1.eglifamily.name";
}


--
Dan Egli
From my Test Server

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

[Neil Bothwick]

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 add --with-tcl=/usr/lib64 to ./configure
> arguments?

Try EXTRA_ECONF="--with-tcl=/usr/lib64" emerge -1a ngspice


-- 
Neil Bothwick

Angular Momentum Makes The World Go 'Round


pgpy87GlXexSd.pgp
Description: OpenPGP digital signature

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

[Michael Orlitzky]

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 reproduce this... I'll take a look.



It looks like the Makefile.am for the documentation was only tested with 
bash. Try e.g.,


  CONFIG_SHELL=/bin/bash USE=doc emerge -v1 sci-libs/amd

If that works for you, I'll add it to the ebuilds.

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

[Michael Orlitzky]

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

[David Haller]

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 works:
>
>destination messages { file("/var/log/messages"); };
>destination maillog { file("/var/log/maillog"); };
>
>filter f_mail { facility(mail); };
>filter f_messages { not facility(mail); };
>
>log { source(src); filter(f_mail); destination(maillog); };
>log { source(src); filter(f_messages); destination(messages); };
>
>On 12/15/2020 10:44 PM, Dan Egli wrote:
>> Help me understand this, please?  I have ISC dhcpd configured to log to
>> syslog.local7 (since I don't see an option to force it into it's own log
>> file). So I went into my syslog-ng file and created two filters, just
>> like on the example page of syslog-ng.com:
>> 
>> filter dhcpmsgs { facility(23) );
>> filter non_dhcp { NOT filter(dhcpmsgs) )

Also, where's that '23' coming from? Shouldn't that be

filter dhcpmsgs { facility(local7); };

HTH,
-dnh

-- 
printk(KERN_DEBUG "%s: Flex. T...\n", DRV_NAME);
linux-2.6.6/drivers/net/wan/dscc4.c

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

[karl]

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 something has interpreted the
initial "\b" as an escape instead of letting it through.
 
# head -1 
/Net/gentoo/tmpdir/portage/sci-libs/amd-2.4.6/work/amd-2.4.6/Doc/amd_h.tex | od 
-a
000  bs   e   g   i   n   {   v   e   r   b   a   t   i   m   }  nl
020
# head -1 
/Net/gentoo/tmpdir/portage/sci-libs/camd-2.4.6/work/camd-2.4.6/Doc/camd_h.tex | 
od -a
000  bs   e   g   i   n   {   v   e   r   b   a   t   i   m   }  nl
020

Do anyone know what to do about it ?

Hälsningar,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sverige
0173 140 57

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

[karl]

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 /usr/lib64/tclConfig.sh

Regards,
/Karl Hammar

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

[Mark Knecht]

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 welcomed. :)
> >
> > Community opinion mostly:
> >
> >
https://serverfault.com/questions/384342/what-are-the-best-practices-of-the-usr-var-and-etc-folders#384345
> > <
https://serverfault.com/questions/384342/what-are-the-best-practices-of-the-usr-var-and-etc-folders#384345
>
> >
> >
> > In this case portage is a 'database'?
>
> Depends what you mean by "portage". Depends what you mean by "database".
>
> 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 - portage the system uses portage the data to
> build the system called gentoo ...
>
> Cheers,
> Wol

Better explanation than my answer/question/comment.

But yes, portage is (I think) a complete system of things, emerge,
depclean, world file and the directories residing under /usr/portage. It's
only that directory structure that changes often and is subject to being
given a description such as 'database'.

Thanks,
Mark

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

[gevisz]

ср, 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 choice didn't win.  :)
>
> There is little dispute that /var makes more sense than /usr other
> than legacy reasons.  /usr is generally used for static data - on some
> distros it might even be read-only, a squashfs, signed using crypto,
> and so on.  On a rolling release distro like Gentoo it might get
> changed often by updates, but other than system updates nothing in it
> should change.  On a more release-based distro only security updates
> or major releases would touch it.
>
> /var on the other hand is used for application data and other things
> that change all the time.  That includes things like databases, which
> the Gentoo repo basically is.  Mail spools, print spools, caches, and
> so on all go on there.
>
> FHS formalizes all this stuff.
>
> 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 repository that
> is entirely stored elsewhere.  Some would certainly disagree with
> that.  I think /var/lib would be an alternative place that keeps more
> to FHS.
>
> However, moving it out of /usr was a move with near-universal support.
> And you can really put it anywhere you want by editing one line in
> your portage config.  I don't think the directory even exists in the
> base install - it gets created the first time you sync so it is
> entirely user-configurable.

Ok, thank you for the explanation.

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

[Dale]

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
>>    repository (by default located at /var/db/repos/gentoo) which already
>>    takes around 650 MiB."
>> that can be found here:
>> https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks ?
>>
>> Have I correctly understood that the Gentoo ebuild repository default
>> location
>> is /var/db/repos/gentoo but virtually everybody relocate it to /usr/
>> during
>> the installation process?
>>
>> Why not change its default location to /usr/ in this case?
>>
>> Where the Gentoo ebuild repository should be allocated? Why?
>
> Wherever you want. I have on /mnt/Data/gentoo/portage, so... meh :P
>
>
>


This is true.  Where can be set in make.conf and
/etc/portage/repos.conf/gentoo.conf.  I have mine in /var/cache here. 
At one point, that seemed to be the place it was going to end up.  Then
it changed after I moved mine.  :/  Examples for OP.

/etc/portage/make.conf:DISTDIR="/var/cache/portage/distfiles/"
/etc/portage/make.conf:PKGDIR="/var/cache/portage/packages"
/etc/portage/repos.conf/gentoo.conf:location = /var/cache/portage/tree

root@fireball / # ls -l /var/cache/portage/
total 152
drwxrwxr-x   3 portage portage 143360 Dec 13 22:42 distfiles
drwxrwxr-x 108 portage portage   4096 Dec 13 22:40 packages
drwxr-xr-x 174 portage portage   4096 Dec 12 18:25 tree
root@fireball / #


OP, with that info, it should help you put it wherever you want.  Don't
forget to check the permissions, owners and group settings too. 

Hope that helps.

Dale

:-)  :-) 

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

[Rich Freeman]

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 - portage the system uses portage the data to
> build the system called gentoo ...

Oh, I would agree that Portage is a database, but if you want to go
with that then /var/lib is the correct location.  /var/db is not where
you would store a database per FHS.  In FHS /var/db doesn't exist at
all. :)

Really the main difference between /var/cache and /var/lib is
value/persistance.  The point of a cache is that you can toss it at
any time and re-create it.  That isn't true of the stuff in /var/lib.
Which bucket the package repo fits into is somewhat nuanced.

-- 
Rich

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

[Victor Ivanov]

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 repository that
is entirely stored elsewhere.  Some would certainly disagree with
that.  I think /var/lib would be an alternative place that keeps more
to FHS.


This is very interesting, thanks for sharing! I was wondering what the 
rationale was behind /var/db but it comes as no surprise that it may 
have something to do with FreeBSD and Gentoo's overall ties/inspiration 
from FreeBSD. Personally, I too agree that /var/cache might be a better 
approach and is commonly used by other distros to store their repos' 
cache (e.g. Debian and derivatives).


Whether it's ultimately the "right" place, I don't know but to me it 
seems one of Linux' larger issues is the general lack of consistency 
between distros. This is a whole other debate of course. And while often 
inconsistencies may stem from otherwise perfectly sound decisions, I 
think such aspects - in their cumulative form - contribute to the 
hindering of wider adoption of Linux outside the tech community.



However, moving it out of /usr was a move with near-universal support.
And you can really put it anywhere you want by editing one line in
your portage config.  I don't think the directory even exists in the
base install - it gets created the first time you sync so it is
entirely user-configurable.


I completely agree with this, I was extremely happy when I read the news 
a while back as it makes far more sense. In fact, prior to the move I 
had been wondering with friends why the repo cache was under /usr.




OpenPGP_signature
Description: OpenPGP digital signature

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

[antlists]

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:

https://serverfault.com/questions/384342/what-are-the-best-practices-of-the-usr-var-and-etc-folders#384345 
 



In this case portage is a 'database'?


Depends what you mean by "portage". Depends what you mean by "database".

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 - portage the system uses portage the data to 
build the system called gentoo ...


Cheers,
Wol

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

[Nikos Chantziaras]

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 /var/db/repos/gentoo) which already
   takes around 650 MiB."
that can be found here:
https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks ?

Have I correctly understood that the Gentoo ebuild repository default location
is /var/db/repos/gentoo but virtually everybody relocate it to /usr/ during
the installation process?

Why not change its default location to /usr/ in this case?

Where the Gentoo ebuild repository should be allocated? Why?


Wherever you want. I have on /mnt/Data/gentoo/portage, so... meh :P

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

[Mark Knecht]

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 this case portage is a 'database'?

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

[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 choice didn't win.  :)

There is little dispute that /var makes more sense than /usr other
than legacy reasons.  /usr is generally used for static data - on some
distros it might even be read-only, a squashfs, signed using crypto,
and so on.  On a rolling release distro like Gentoo it might get
changed often by updates, but other than system updates nothing in it
should change.  On a more release-based distro only security updates
or major releases would touch it.

/var on the other hand is used for application data and other things
that change all the time.  That includes things like databases, which
the Gentoo repo basically is.  Mail spools, print spools, caches, and
so on all go on there.

FHS formalizes all this stuff.

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 repository that
is entirely stored elsewhere.  Some would certainly disagree with
that.  I think /var/lib would be an alternative place that keeps more
to FHS.

However, moving it out of /usr was a move with near-universal support.
And you can really put it anywhere you want by editing one line in
your portage config.  I don't think the directory even exists in the
base install - it gets created the first time you sync so it is
entirely user-configurable.

-- 
Rich

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

[gevisz]

> 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 default located at /var/db/repos/gentoo) which already
> >   takes around 650 MiB."
> > that can be found here:
> > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks ?
> >
> > Have I correctly understood that the Gentoo ebuild repository default 
> > location
> > is /var/db/repos/gentoo but virtually everybody relocate it to /usr/ during
> > the installation process?
> >
> > Why not change its default location to /usr/ in this case?
> >
> > Where the Gentoo ebuild repository should be allocated? Why?
> >
> On Wed, 16 Dec 2020 at 13:55, Miles Malone :
>
> 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

Thank you for your reply. Now, it is a bit clearer.

Nevertheless, the explanation why /var/db/repos/gentoo is better than
/usr/portage is still welcomed. :)

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

[Todd Goodman]

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 { file("/var/log/messages"); };
destination maillog { file("/var/log/maillog"); };

filter f_mail { facility(mail); };
filter f_messages { not facility(mail); };

log { source(src); filter(f_mail); destination(maillog); };
log { source(src); filter(f_messages); destination(messages); };

On 12/15/2020 10:44 PM, Dan Egli wrote:
Help me understand this, please?  I have ISC dhcpd configured to log 
to syslog.local7 (since I don't see an option to force it into it's 
own log file). So I went into my syslog-ng file and created two 
filters, just like on the example page of syslog-ng.com:


filter dhcpmsgs { facility(23) );
filter non_dhcp { NOT filter(dhcpmsgs) )

I quoted almost directly from the example page on syslog-ng.com, but I 
keep getting this error when I reload syslog-ng's config:
Error parsing filter expression, filter plugin NOT not found OR you 
may not used double quotes in your filter expression in 
/etc/syslog-ng/syslog-ng.conf:25:18-25:21:


What did I do wrong? Here's the lines I modified from the syslog-ng page:
filter demo_filter { host("example") and match("deny" 
value("MESSAGE")) };

filter inverted_demo_filter { NOT filter(demo_filter) }

You can see the page at: 
https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.16/administration-guide/53

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

[Dale]

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 us 51 years
>
>

That's true for me too.  I sometimes do my updates in a chroot and then
install binaries on my main install when it is done.  It's also a good
idea to check the USE flag changes as well.  Sometimes a new USE flag is
added or one that used to default to enabled is now defaulting to
disabled or vice versa.  If you see the change, it gives you a chance to
edit the correct config file to get the result you want.  Before -a came
along, everyone did a -p which meant removing the -p and running again
to do a update.  The -a gives you a chance to look and then proceed if
all looks right without having to run emerge again.  Sometimes it can
take a while for emerge to process what gets done. 

It's rare, very rare, that I run a emerge command without -a.  I always
check what will be done first. 

Dale

:-)  :-) 

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

[Miles Malone]

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 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 MiB."
> that can be found here:
> https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks ?
>
> Have I correctly understood that the Gentoo ebuild repository default location
> is /var/db/repos/gentoo but virtually everybody relocate it to /usr/ during
> the installation process?
>
> Why not change its default location to /usr/ in this case?
>
> Where the Gentoo ebuild repository should be allocated? Why?
>

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

[gevisz]

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 MiB."
that can be found here:
https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks ?

Have I correctly understood that the Gentoo ebuild repository default location
is /var/db/repos/gentoo but virtually everybody relocate it to /usr/ during
the installation process?

Why not change its default location to /usr/ in this case?

Where the Gentoo ebuild repository should be allocated? Why?

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

[Miles Malone]

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 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
> > --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 if I've tried that combination, I'll do so now.
>
>
> ... you include -a.  Under what situation might I respond to the prompt
> with 'no'?
>
>
>
> >
> > On Wed, 16 Dec 2020 at 20:24, n952162  wrote:
> >> 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 collision:
> >>
> >> dev-python/jinja:0
> >>
> >>(dev-python/jinja-2.11.2-r1:0/0::gentoo, ebuild scheduled for merge) 
> >> USE="-doc -examples -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 
> >> python3_9 (-pypy3) -python3_6 -python3_7" pulled in by
> >>  
> >> dev-python/jinja[python_targets_python3_9(-),python_single_target_python3_9(+)]
> >>  required by (sys-auth/pambase-20201103:0/0::gentoo, ebuild scheduled for 
> >> merge) USE="nullok passwdqc sha512 -caps -debug -elogind -gnome-keyring 
> >> -minimal -mktemp -pam_krb5 -pam_ssh -pwhistory -pwquality -securetty 
> >> (-selinux) -systemd" ABI_X86="(64)"
> >>
> >>
> >>  dev-python/jinja (Argument)
> >>
> >>(dev-python/jinja-2.11.2-r1:0/0::gentoo, installed) USE="-doc -examples 
> >> -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 
> >> -python3_8 -python3_9" pulled in by
> >>  
> >> dev-python/jinja[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
> >>  required by (dev-python/sphinx-3.2.1:0/0::gentoo, installed) USE="-doc 
> >> -latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 
> >> -python3_8 -python3_9"
> >>
> >> If the package was good enough before, it's likely still good enough.  
> >> Where's the problem?  I've (unsuccessfully) made these attempts:
> >>
> >> # */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
> >> #*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
> >> # just have one set
> >> */* PYTHON_TARGETS: python3_8
> >>
> >> The sphinx ebuild has no targets, but does have this:
> >>
> >> PYTHON_COMPAT=( python3_{6..9} pypy3 )
> >>
> >> The emerge command was:
> >>
> >> sudo emerge --verbose=y -vuUD   --verbose-conflicts   
> >> dev-python/setuptools dev-python/setuptools_scm dev-python/certifi 
> >> dev-python/markupsafe dev-python/jinja dev-libs/libxml2
> >>
> >>
>

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

[Miles Malone]

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
> > --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 if I've tried that combination, I'll do so now.
>
>
> ... you include -a.  Under what situation might I respond to the prompt
> with 'no'?
>
>
>
> >
> > On Wed, 16 Dec 2020 at 20:24, n952162  wrote:
> >> 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 collision:
> >>
> >> dev-python/jinja:0
> >>
> >>(dev-python/jinja-2.11.2-r1:0/0::gentoo, ebuild scheduled for merge) 
> >> USE="-doc -examples -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 
> >> python3_9 (-pypy3) -python3_6 -python3_7" pulled in by
> >>  
> >> dev-python/jinja[python_targets_python3_9(-),python_single_target_python3_9(+)]
> >>  required by (sys-auth/pambase-20201103:0/0::gentoo, ebuild scheduled for 
> >> merge) USE="nullok passwdqc sha512 -caps -debug -elogind -gnome-keyring 
> >> -minimal -mktemp -pam_krb5 -pam_ssh -pwhistory -pwquality -securetty 
> >> (-selinux) -systemd" ABI_X86="(64)"
> >>
> >>
> >>  dev-python/jinja (Argument)
> >>
> >>(dev-python/jinja-2.11.2-r1:0/0::gentoo, installed) USE="-doc -examples 
> >> -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 
> >> -python3_8 -python3_9" pulled in by
> >>  
> >> dev-python/jinja[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
> >>  required by (dev-python/sphinx-3.2.1:0/0::gentoo, installed) USE="-doc 
> >> -latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 
> >> -python3_8 -python3_9"
> >>
> >> If the package was good enough before, it's likely still good enough.  
> >> Where's the problem?  I've (unsuccessfully) made these attempts:
> >>
> >> # */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
> >> #*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
> >> # just have one set
> >> */* PYTHON_TARGETS: python3_8
> >>
> >> The sphinx ebuild has no targets, but does have this:
> >>
> >> PYTHON_COMPAT=( python3_{6..9} pypy3 )
> >>
> >> The emerge command was:
> >>
> >> sudo emerge --verbose=y -vuUD   --verbose-conflicts   
> >> dev-python/setuptools dev-python/setuptools_scm dev-python/certifi 
> >> dev-python/markupsafe dev-python/jinja dev-libs/libxml2
> >>
> >>
>

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

[n952162]

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 if I've tried that combination, I'll do so now.


... you include -a.  Under what situation might I respond to the prompt
with 'no'?





On Wed, 16 Dec 2020 at 20:24, n952162  wrote:

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

dev-python/jinja:0

   (dev-python/jinja-2.11.2-r1:0/0::gentoo, ebuild scheduled for merge) USE="-doc -examples -test" 
ABI_X86="(64)" PYTHON_TARGETS="python3_8 python3_9 (-pypy3) -python3_6 -python3_7" pulled 
in by
 dev-python/jinja[python_targets_python3_9(-),python_single_target_python3_9(+)] required by 
(sys-auth/pambase-20201103:0/0::gentoo, ebuild scheduled for merge) USE="nullok passwdqc 
sha512 -caps -debug -elogind -gnome-keyring -minimal -mktemp -pam_krb5 -pam_ssh -pwhistory 
-pwquality -securetty (-selinux) -systemd" ABI_X86="(64)"


 dev-python/jinja (Argument)

   (dev-python/jinja-2.11.2-r1:0/0::gentoo, installed) USE="-doc -examples -test" 
ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 -python3_9" 
pulled in by
 
dev-python/jinja[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
 required by (dev-python/sphinx-3.2.1:0/0::gentoo, installed) USE="-doc -latex -test" 
ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 -python3_9"

If the package was good enough before, it's likely still good enough.  Where's 
the problem?  I've (unsuccessfully) made these attempts:

# */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
#*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
# just have one set
*/* PYTHON_TARGETS: python3_8

The sphinx ebuild has no targets, but does have this:

PYTHON_COMPAT=( python3_{6..9} pypy3 )

The emerge command was:

sudo emerge --verbose=y -vuUD   --verbose-conflicts   dev-python/setuptools 
dev-python/setuptools_scm dev-python/certifi dev-python/markupsafe 
dev-python/jinja dev-libs/libxml2

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

[Arve Barsnes]

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 should definitely try this first if you haven't.

> > If the package was good enough before, it's likely still good enough.  
> > Where's the problem?  I've (unsuccessfully) made these attempts:
> >
> > # */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
> > #*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
> > # just have one set
> > */* PYTHON_TARGETS: python3_8

Is there any reason that you need to add py3.9 to all packages? If you
need it for something special, add it to those packages only, and let
portage take care of python targets for you instead of continuously
trying these big hammers. Ideally you should have *no* python targets
set manually in make.conf or USE files.

> > The emerge command was:
> >
> > sudo emerge --verbose=y -vuUD   --verbose-conflicts   dev-python/setuptools 
> > dev-python/setuptools_scm dev-python/certifi dev-python/markupsafe 
> > dev-python/jinja dev-libs/libxml2

Since it seems sphinx is installed with a different set of python
targets than what you're trying to update, you should include sphinx
in that emerge command to let it update to the same python targets and
solve the conflict.

Regards,
Arve

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

[bobwxc]

在 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 PYTHON_TARGETS of the dependency?

Slot collision:

dev-python/jinja:0

  (dev-python/jinja-2.11.2-r1:0/0::gentoo, ebuild scheduled for merge) 
USE="-doc -examples -test" ABI_X86="(64)" PYTHON_TARGETS="*python3_8 
python3_9 (-pypy3) -python3_6 -python3_7*" pulled in by
dev-python/jinja[python_targets_python3_9(-),python_single_target_python3_9(+)] 
required by (sys-auth/pambase-20201103:0/0::gentoo, ebuild scheduled 
for merge) USE="nullok passwdqc sha512 -caps -debug -elogind 
-gnome-keyring -minimal -mktemp -pam_krb5 -pam_ssh -pwhistory 
-pwquality -securetty (-selinux) -systemd" ABI_X86="(64)"



    dev-python/jinja (Argument)

  (dev-python/jinja-2.11.2-r1:0/0::gentoo, installed) USE="-doc 
-examples -test" ABI_X86="(64)" PYTHON_TARGETS="*python3_7 (-pypy3) 
-python3_6 -python3_8 -python3_9*" pulled in by
dev-python/jinja[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] 
required by (dev-python/sphinx-3.2.1:0/0::gentoo, installed) USE="-doc 
-latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) 
-python3_6 -python3_8 -python3_9"


If the package was good enough before, it's likely still good enough.  
Where's the problem?  I've (unsuccessfully) made these attempts:


# */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
#*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
# just have one set
*/* PYTHON_TARGETS: python3_8

The sphinx ebuild has no targets, but does have this:

PYTHON_COMPAT=( python3_{6..9} pypy3 )

The emerge command was:

sudo emerge --verbose=y -vuUD --verbose-conflicts   
dev-python/setuptools dev-python/setuptools_scm dev-python/certifi 
dev-python/markupsafe dev-python/jinja dev-libs/libxml2



According to the 
https://wiki.gentoo.org/wiki/Project:Python/PYTHON_TARGETS and your log


may be set like

# Replacing the profile default with specific implementation
dev-python/* PYTHON_SINGLE_TARGET: python3_6

That will let all the dev-python target set to python3_6

--
bobwxc




OpenPGP_signature
Description: OpenPGP digital signature

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

[Miles Malone]

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 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 collision:
>
> dev-python/jinja:0
>
>   (dev-python/jinja-2.11.2-r1:0/0::gentoo, ebuild scheduled for merge) 
> USE="-doc -examples -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 python3_9 
> (-pypy3) -python3_6 -python3_7" pulled in by
> 
> dev-python/jinja[python_targets_python3_9(-),python_single_target_python3_9(+)]
>  required by (sys-auth/pambase-20201103:0/0::gentoo, ebuild scheduled for 
> merge) USE="nullok passwdqc sha512 -caps -debug -elogind -gnome-keyring 
> -minimal -mktemp -pam_krb5 -pam_ssh -pwhistory -pwquality -securetty 
> (-selinux) -systemd" ABI_X86="(64)"
>
>
> dev-python/jinja (Argument)
>
>   (dev-python/jinja-2.11.2-r1:0/0::gentoo, installed) USE="-doc -examples 
> -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 
> -python3_8 -python3_9" pulled in by
> 
> dev-python/jinja[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
>  required by (dev-python/sphinx-3.2.1:0/0::gentoo, installed) USE="-doc 
> -latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 
> -python3_8 -python3_9"
>
> If the package was good enough before, it's likely still good enough.  
> Where's the problem?  I've (unsuccessfully) made these attempts:
>
> # */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
> #*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
> # just have one set
> */* PYTHON_TARGETS: python3_8
>
> The sphinx ebuild has no targets, but does have this:
>
> PYTHON_COMPAT=( python3_{6..9} pypy3 )
>
> The emerge command was:
>
> sudo emerge --verbose=y -vuUD   --verbose-conflicts   dev-python/setuptools 
> dev-python/setuptools_scm dev-python/certifi dev-python/markupsafe 
> dev-python/jinja dev-libs/libxml2
>
>

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

[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 PYTHON_TARGETS of the dependency?

Slot collision:

dev-python/jinja:0

  (dev-python/jinja-2.11.2-r1:0/0::gentoo, ebuild scheduled for merge)
USE="-doc -examples -test" ABI_X86="(64)" PYTHON_TARGETS="*python3_8
python3_9 (-pypy3) -python3_6 -python3_7*" pulled in by
dev-python/jinja[python_targets_python3_9(-),python_single_target_python3_9(+)]
required by (sys-auth/pambase-20201103:0/0::gentoo, ebuild scheduled for
merge) USE="nullok passwdqc sha512 -caps -debug -elogind -gnome-keyring
-minimal -mktemp -pam_krb5 -pam_ssh -pwhistory -pwquality -securetty
(-selinux) -systemd" ABI_X86="(64)"


    dev-python/jinja (Argument)

  (dev-python/jinja-2.11.2-r1:0/0::gentoo, installed) USE="-doc
-examples -test" ABI_X86="(64)" PYTHON_TARGETS="*python3_7 (-pypy3)
-python3_6 -python3_8 -python3_9*" pulled in by
dev-python/jinja[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (dev-python/sphinx-3.2.1:0/0::gentoo, installed) USE="-doc
-latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3)
-python3_6 -python3_8 -python3_9"

If the package was good enough before, it's likely still good enough. 
Where's the problem?  I've (unsuccessfully) made these attempts:

# */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
#*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
# just have one set
*/* PYTHON_TARGETS: python3_8

The sphinx ebuild has no targets, but does have this:

PYTHON_COMPAT=( python3_{6..9} pypy3 )

The emerge command was:

sudo emerge --verbose=y -vuUD --verbose-conflicts  
dev-python/setuptools dev-python/setuptools_scm dev-python/certifi
dev-python/markupsafe dev-python/jinja dev-libs/libxml2


# vim: syntax=emerge-out

These are the packages that would be merged, in order:

Calculating dependencies  
 * IMPORTANT: 9 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.

 * See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
 * sections of the emerge man page to learn how to update config files.
.  done!
[ebuild U  ] sys-libs/glibc-2.32-r2:2.2::gentoo [2.31-r6:2.2::gentoo] 
USE="(crypt) multiarch (multilib) ssp (static-libs) -audit -caps (-cet) 
-compile-locales -custom-cflags -doc -gd -headers-only -nscd -profile 
(-selinux) -static-pie -suid -systemtap -test (-vanilla)" 16369 KiB
[ebuild U  ] sys-libs/timezone-data-2020d::gentoo [2020a::gentoo] USE="nls 
-leaps-timezone -zic-slim%" 647 KiB
[ebuild U  ] sys-devel/gcc-config-2.3.2-r1::gentoo [2.3.2::gentoo] 
USE="(cc-wrappers%*) (native-symlinks)" 0 KiB
[ebuild U  ] virtual/tmpfiles-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild U  ] dev-libs/mpc-1.2.1:0/3::gentoo [1.2.0:0/3::gentoo] 
USE="-static-libs" ABI_X86="(64) -32 (-x32)" 820 KiB
[ebuild U  ] sys-libs/libseccomp-2.4.4::gentoo [2.4.3::gentoo] 
USE="-static-libs" ABI_X86="(64) -32 (-x32)" 591 KiB
[ebuild   R] sys-apps/file-5.39-r3::gentoo  USE="bzip2 seccomp zlib -lzma 
-python -static-libs" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_8* 
python3_9* -python3_6 -python3_7*" 0 KiB
[ebuild   R] app-misc/pax-utils-1.2.6::gentoo  USE="seccomp -caps -debug 
-python" PYTHON_SINGLE_TARGET="python3_9%* -python3_6 -python3_7* -python3_8" 0 
KiB
[ebuild U  ] sys-apps/sandbox-2.20::gentoo [2.18::gentoo] ABI_X86="(32) 
(64) (-x32)" 419 KiB
[ebuild U  ] dev-libs/openssl-1.1.1i:0/1.1::gentoo [1.1.1g:0/1.1::gentoo] 
USE="asm zlib -bindist -rfc3779 -sctp -sslv3 -static-libs -test -tls-heartbeat 
-vanilla" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="(sse2)" 9579 KiB
[ebuild U  ] sys-devel/automake-1.16.2-r1:1.16::gentoo 
[1.16.1-r1:1.16::gentoo] USE="-test" 1510 KiB
[ebuild U  ] sys-libs/gdbm-1.18.1-r1:0/6::gentoo [1.18.1:0/6::gentoo] 
USE="berkdb nls readline -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild U  ] sys-apps/attr-2.4.48-r4::gentoo [2.4.48-r3::gentoo] USE="nls 
(split-usr) -debug -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild U  ] sys-apps/grep-3.5::gentoo [3.4::gentoo] USE="nls pcre -static" 
1550 KiB
[ebuild U  ] dev-libs/popt-1.18::gentoo [1.16-r2::gentoo] USE="nls 
-static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild U  ] sys-devel/bison-3.7.3::gentoo [3.7.1-r1::gentoo] USE="nls 
-examples -static -test" 2563 KiB
[ebuild U  ] app-crypt/gnupg-2.2.20-r2::gentoo [2.2.20-r1::gentoo] 
USE="bzip2 nls readline smartcard ssl -doc -ldap (-selinux) -tofu -tools -usb 
-user-socket -wks-server" 0 KiB
[ebuild U  ]