Re: [gentoo-user] Upgrade problems with the latest llvm/clang

2024-07-24 Thread Jack
Sorry for the delay, but yes, after re-syncing, everything is working  
correctly.


Thanks for the info.

On 2024.07.23 17:52, Eli Schwartz wrote:

On 7/23/24 5:37 PM, Jack wrote:
> The latest eix-sync included clang and llvm 18.  Unfortunately, a  
full

> emerge upgrade complains
>
> - media-libs/mesa-24.1.3::gentoo USE="X llvm lm-sensors (opengl)
> proprietary-codecs vaapi vulkan wayland zstd -d3d9 -debug -opencl
> -osmesa (-selinux) -test -unwind -valgrind -vdpau -vulkan-overlay  
-xa"

> ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="sse2" LLVM_SLOT="-15 -16 -17
> (-18)" VIDEO_CARDS="radeon radeonsi -d3d12 (-freedreno) -intel  
-lavapipe

> (-lima) -nouveau (-nvk) (-panfrost) -r300 -r600 (-v3d) (-vc4) -virgl
> (-vivante) -vmware -zink"
>
>   The following REQUIRED_USE flag constraints are unsatisfied:
>     llvm? ( exactly-one-of ( llvm_slot_15 llvm_slot_16 llvm_slot_17
> llvm_slot_18 ) )
>
> The problem is that I don't know why one of the llvm slots is NOT  
selected.

>
> "emerge --info mesa" includes:
>
> USE="X llvm lm-sensors (opengl) proprietary-codecs vaapi vulkan  
wayland

> zstd -d3d9 -debug -opencl -osmesa (-selinux) -test -unwind -valgrind
> -vdpau -vulkan-overlay -xa" ABI_X86="32 (64) (-x32)"
> CPU_FLAGS_X86="sse2" LLVM_SLOT="17 -15 -16 (-18)"  
VIDEO_CARDS="radeon
> radeonsi -d3d12 (-freedreno) -intel -lavapipe (-lima) -nouveau  
(-nvk)
> (-panfrost) -r300 -r600 (-v3d) (-vc4) -virgl (-vivante) -vmware  
-zink"

>
> which shows slot 17 IS selected.
>
> "grep -ir llvm /etc/portage" only shows sys-devel/llvm abi_x86_32  
in one

> of the package.use files.
>
> My profile is
>  default/linux/amd64/23.0/desktop/plasma (stable) *
>
> I find no relevant bug filed, and nothing related on the forums.   
What

> fine manual have I apparently neglected to read?


The default in the ebuild's IUSE (via +llvm_slot_* ) is now LLVM 18,  
not

17, the upgrade is complaining that nothing is selected *at all*.

The underlying issue is that 18 is the default, but it is also force
masked on stable, which was a small mistake during stabilization. and
eclass bumping. It was shortly after rectified by removing the  
outdated

mask in profiles/base/use.stable.mask

Try syncing again. The llvm 18 slot bump was 8 hours ago, and the
use.stable.mask fix was 4 hours ago.

The bug for this is really just https://bugs.gentoo.org/935984#c13  
(the

stabilization bug for llvm 18).


--
Eli Schwartz







[gentoo-user] CUPS and printer serial numbers

2024-07-24 Thread Peter Humphrey
Hello list,

Is it possible to get CUPS to report the serial number of a network-connected 
printer?

-- 
Regards,
Peter.






Re: [gentoo-user] Upgrade problems with the latest llvm/clang

2024-07-23 Thread Eli Schwartz
On 7/23/24 5:37 PM, Jack wrote:
> The latest eix-sync included clang and llvm 18.  Unfortunately, a full
> emerge upgrade complains
> 
> - media-libs/mesa-24.1.3::gentoo USE="X llvm lm-sensors (opengl)
> proprietary-codecs vaapi vulkan wayland zstd -d3d9 -debug -opencl
> -osmesa (-selinux) -test -unwind -valgrind -vdpau -vulkan-overlay -xa"
> ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="sse2" LLVM_SLOT="-15 -16 -17
> (-18)" VIDEO_CARDS="radeon radeonsi -d3d12 (-freedreno) -intel -lavapipe
> (-lima) -nouveau (-nvk) (-panfrost) -r300 -r600 (-v3d) (-vc4) -virgl
> (-vivante) -vmware -zink"
> 
>   The following REQUIRED_USE flag constraints are unsatisfied:
>     llvm? ( exactly-one-of ( llvm_slot_15 llvm_slot_16 llvm_slot_17
> llvm_slot_18 ) )
> 
> The problem is that I don't know why one of the llvm slots is NOT selected.
> 
> "emerge --info mesa" includes:
> 
> USE="X llvm lm-sensors (opengl) proprietary-codecs vaapi vulkan wayland
> zstd -d3d9 -debug -opencl -osmesa (-selinux) -test -unwind -valgrind
> -vdpau -vulkan-overlay -xa" ABI_X86="32 (64) (-x32)"
> CPU_FLAGS_X86="sse2" LLVM_SLOT="17 -15 -16 (-18)" VIDEO_CARDS="radeon
> radeonsi -d3d12 (-freedreno) -intel -lavapipe (-lima) -nouveau (-nvk)
> (-panfrost) -r300 -r600 (-v3d) (-vc4) -virgl (-vivante) -vmware -zink"
> 
> which shows slot 17 IS selected.
> 
> "grep -ir llvm /etc/portage" only shows sys-devel/llvm abi_x86_32 in one
> of the package.use files.
> 
> My profile is
>  default/linux/amd64/23.0/desktop/plasma (stable) *
> 
> I find no relevant bug filed, and nothing related on the forums.  What
> fine manual have I apparently neglected to read?


The default in the ebuild's IUSE (via +llvm_slot_* ) is now LLVM 18, not
17, the upgrade is complaining that nothing is selected *at all*.

The underlying issue is that 18 is the default, but it is also force
masked on stable, which was a small mistake during stabilization. and
eclass bumping. It was shortly after rectified by removing the outdated
mask in profiles/base/use.stable.mask

Try syncing again. The llvm 18 slot bump was 8 hours ago, and the
use.stable.mask fix was 4 hours ago.

The bug for this is really just https://bugs.gentoo.org/935984#c13 (the
stabilization bug for llvm 18).


-- 
Eli Schwartz



OpenPGP_signature.asc
Description: OpenPGP digital signature


[gentoo-user] Upgrade problems with the latest llvm/clang

2024-07-23 Thread Jack
The latest eix-sync included clang and llvm 18.  Unfortunately, a full  
emerge upgrade complains


- media-libs/mesa-24.1.3::gentoo USE="X llvm lm-sensors (opengl)  
proprietary-codecs vaapi vulkan wayland zstd -d3d9 -debug -opencl  
-osmesa (-selinux) -test -unwind -valgrind -vdpau -vulkan-overlay -xa"  
ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="sse2" LLVM_SLOT="-15 -16 -17  
(-18)" VIDEO_CARDS="radeon radeonsi -d3d12 (-freedreno) -intel  
-lavapipe (-lima) -nouveau (-nvk) (-panfrost) -r300 -r600 (-v3d) (-vc4)  
-virgl (-vivante) -vmware -zink"


  The following REQUIRED_USE flag constraints are unsatisfied:
llvm? ( exactly-one-of ( llvm_slot_15 llvm_slot_16 llvm_slot_17  
llvm_slot_18 ) )


The problem is that I don't know why one of the llvm slots is NOT  
selected.


"emerge --info mesa" includes:

USE="X llvm lm-sensors (opengl) proprietary-codecs vaapi vulkan wayland  
zstd -d3d9 -debug -opencl -osmesa (-selinux) -test -unwind -valgrind  
-vdpau -vulkan-overlay -xa" ABI_X86="32 (64) (-x32)"  
CPU_FLAGS_X86="sse2" LLVM_SLOT="17 -15 -16 (-18)" VIDEO_CARDS="radeon  
radeonsi -d3d12 (-freedreno) -intel -lavapipe (-lima) -nouveau (-nvk)  
(-panfrost) -r300 -r600 (-v3d) (-vc4) -virgl (-vivante) -vmware -zink"


which shows slot 17 IS selected.

"grep -ir llvm /etc/portage" only shows sys-devel/llvm abi_x86_32 in  
one of the package.use files.


My profile is
 default/linux/amd64/23.0/desktop/plasma (stable) *

I find no relevant bug filed, and nothing related on the forums.  What  
fine manual have I apparently neglected to read?


Jack



Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-22 Thread Michael
On Sunday, 21 July 2024 16:20:54 BST Frank Steinmetzger wrote:
> Oopsie, I found this mail in my drafts folder just now, where it’s been
> sitting since the ninth. Perhaps I had to pause writing, but now I can’t
> remember anymore. So I’ll just send it off. ;-)
> 
> Am Tue, Jul 09, 2024 at 12:02:47AM +0100 schrieb Michael:
> > On Monday, 8 July 2024 21:21:19 BST Frank Steinmetzger wrote:
> > > Am Mon, Jul 08, 2024 at 06:26:26PM +0100 schrieb Michael:
> > > > Back to the previous topic, I have not yet found a case where changing
> > > > the
> > > > scale by means of the desktop settings, arrives at non-blurred fonts. 
> > > > The
> > > > clearest sharpest fonts are always rendered at the native monitor
> > > > resolution, at a 100% scale setting.  Am I missing a trick, or is this
> > > > to
> > > > be expected?
> > > 
> > > That doesn’t really make sense. Fonts are always rendered natively, no
> > > matter what size. Except if they are really rendered at 100 % and then
> > > the
> > > rendered bitmap is scaled by the GPU or somesuch.
> > > 
> > > Or because their hinting information is limited to a certain size range.
> > > This info gives the renderer special knowledge on how to render the
> > > glyphs.
> > > 
> > > Do you have screenshots?
> > 
> > I attach two screenshots one at 100% and one at 90%.  When viewed on the
> > 1366x768 actual monitor they are worse than what the screenshots have
> > captured.  Perhaps I need to take a photo of the monitor.  Anyway, if you
> > view it on a 1920x1080 monitor you should hopefully see the difference. 
> > The font DPI is 96.
> 
> I can see it. I use 2560×1440, but viewing an image pixel-perfect is not
> dependent on the screen’s resolution per se, but on it being run at its
> native resolution. So that one pixel in the image is actually displayed by
> one pixel on the screen without any scaling-induced blurring.
> 
> I have no real explanation for the fonts. Do they also get blurry at scales
> bigger than 100 %? 

I'll check this when I'm next at that PC.


> The only thing I can say is that I use a font setting of
> slight hinting with no RGB subpixel rendering. The latter means that I don’t
> want the coloured fringes, but prefer greyscale aliasing instead. See my
> screenshot. 96 dpi (100 % scaling), main fonts set to 11 pt.

I can see the slight hinting on your screenshot.  On a same resolution monitor 
(2560×1440), I have:

General font Noto Sans 10pt,
Fixed width Hack 10pt 
RGB sub-pixel rendering
slight hinting,  

mine look (very slightly) less blurred with naked eye.  However, this may have 
to do with the choice of font and of course the monitor panel construction.

Something else which affects font rendering is the selections on fontconfig.  
A lot of mine are unset - not sure what I should/shouldn't have enabled:

~ $ eselect fontconfig list
Available fontconfig .conf files (* is enabled):
  [1]   05-reset-dirs-sample.conf
  [2]   09-autohint-if-no-hinting.conf
  [3]   10-autohint.conf
  [4]   10-hinting-full.conf
  [5]   10-hinting-medium.conf
  [6]   10-hinting-none.conf
  [7]   10-hinting-slight.conf *
  [8]   10-no-antialias.conf
  [9]   10-scale-bitmap-fonts.conf *
  [10]  10-sub-pixel-bgr.conf
  [11]  10-sub-pixel-none.conf *
  [12]  10-sub-pixel-rgb.conf
  [13]  10-sub-pixel-vbgr.conf
  [14]  10-sub-pixel-vrgb.conf
  [15]  10-unhinted.conf
  [16]  10-yes-antialias.conf *
  [17]  11-lcdfilter-default.conf *
  [18]  11-lcdfilter-legacy.conf *
  [19]  11-lcdfilter-light.conf *
  [20]  11-lcdfilter-none.conf
  [21]  20-unhint-small-dejavu-sans.conf *
  [22]  20-unhint-small-dejavu-sans-mono.conf *
  [23]  20-unhint-small-dejavu-serif.conf *
  [24]  20-unhint-small-vera.conf *
  [25]  25-unhint-nonlatin.conf
  [26]  30-metric-aliases.conf *
  [27]  35-lang-normalize.conf
  [28]  40-nonlatin.conf *
  [29]  45-generic.conf *
  [30]  45-latin.conf *
  [31]  48-spacing.conf *
  [32]  49-sansserif.conf *
  [33]  50-user.conf *
  [34]  51-local.conf *
  [35]  57-dejavu-sans.conf *
  [36]  57-dejavu-sans-mono.conf *
  [37]  57-dejavu-serif.conf *
  [38]  60-generic.conf *
  [39]  60-latin.conf *
  [40]  60-liberation.conf *
  [41]  61-urw-bookman.conf *
  [42]  61-urw-c059.conf *
  [43]  61-urw-d05l.conf *
  [44]  61-urw-fallback-backwards.conf *
  [45]  61-urw-fallback-generics.conf *
  [46]  61-urw-fallback-specifics.conf *
  [47]  61-urw-gothic.conf *
  [48]  61-urw-nimbus-mono-ps.conf *
  [49]  61-urw-nimbus-roman.conf *
  [50]  61-urw-nimbus-sans.conf *
  [51]  61-urw-p052.conf *
  [52]  61-urw-standard-symbols-ps.conf *
  [53]  61-urw-z003.conf *
  [54]  65-fonts-persian.conf *
  [55]  65-khmer.conf
  [56]  65-nonlatin.conf
  [57]  66-noto-mono.conf *
  [58]  66-noto-sans.conf *
  [59]  66-noto-serif.conf *
  [60]  69-unifont.conf *
  [61]  70-no-bitmaps.conf
  [62]  70-yes-bitmaps.conf
  [63]  75-noto-emoji-fallback.conf *
  [64]  80-delicious.conf *
  [65]  90-synthetic.conf *


> I used to use full hinting in my early (KDE 3) days, which 

Re: [gentoo-user] wpa_supplicant: Wi-Fi works for all points, excluding one in the caffee

2024-07-21 Thread William Kenworthy

In this line it looks like a space after "Lali" ...

BillK



On 22/7/24 00:19, Vitaly Zdanevich wrote:
wlp3s0: 3: a0:8c:f8:78:01:50 ssid='Lali ' wpa_ie_len=26 rsn_ie_len=24 
caps=0x1411 level=-59 freq=243




Re: [gentoo-user] wpa_supplicant: Wi-Fi works for all points, excluding one in the caffee

2024-07-21 Thread Vitaly Zdanevich

SOLVED - name has space at the end.

On 7/21/24 20:19, Vitaly Zdanevich wrote:


Hi, my old Android 8 phone and Ubuntu on the same laptop connects to 
this point, but not Gentoo.


I see this point in `wpa_cli scan_result` as

[WPA-PSK-CCMP+TKIP][WPA2-PSK-CCMP+TKIP][ESS] Lali

My config in the same format as for other points:

network={
    ssid="Lali"
    psk="mypass"
    priority=1
}



[gentoo-user] wpa_supplicant: Wi-Fi works for all points, excluding one in the caffee

2024-07-21 Thread Vitaly Zdanevich
Hi, my old Android 8 phone and Ubuntu on the same laptop connects to 
this point, but not Gentoo.


I see this point in `wpa_cli scan_result` as

[WPA-PSK-CCMP+TKIP][WPA2-PSK-CCMP+TKIP][ESS] Lali

My config in the same format as for other points:

network={
    ssid="Lali"
    psk="mypass"
    priority=1
}

wpa_cli log like this point not exists - Gentoo not even trying to connect:

<3>CTRL-EVENT-NETWORK-NOT-FOUND
<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS
<3>CTRL-EVENT-NETWORK-NOT-FOUND
<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS
<3>CTRL-EVENT-NETWORK-NOT-FOUND
<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS
<3>CTRL-EVENT-NETWORK-NOT-FOUND

I tried direct connect:

wpa_supplicant -i wlp3s0 -c <(wpa_passphrase Lali mypass)

and got

nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-16 retry=1

I enabled debug as

wpa_supplicant -dd -i wlp3s0 -c /etc/wpa_supplicant/wpa_supplicant.conf

but related to this point I see only

wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0: 3: a0:8c:f8:78:01:50 ssid='Lali ' wpa_ie_len=26 rsn_ie_len=24 
caps=0x1411 level=-59 freq=2432

wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch
wlp3s0:    skip - SSID mismatch

like for other unavailable points


$ equery u wpa_supplicant
[ Legend : U - final flag setting for installation]
[    : I - package is installed with flag ]
[ Colors : set, unset ]
 * Found these USE flags for net-wireless/wpa_supplicant-2.10-r4:
 U I
 - - ap : Add support for access point mode
 - - broadcom-sta   : Flag to help users disable features not 
supported by broadcom-sta driver
 + + dbus   : Enable dbus support for anything that needs 
it (gpsd, gnomemeeting, etc)

 - - eap-sim    : Add support for EAP-SIM authentication algorithm
 - - eapol-test : Build and install eapol_test binary
 - - fasteap    : Add support for FAST-EAP authentication algorithm
 + + fils   : Add support for Fast Initial Link Setup 
(802.11ai)
 + + hs2-0  : Add support for 802.11u and Passpoint for 
HotSpot 2.0

 - - macsec : Add support for wired macsec
 + + mbo    : Add support Multiband Operation
 + + mesh   : Add support for mesh mode
 - - p2p    : Add support for Wi-Fi Direct mode
 - - privsep    : Enable wpa_priv privledge separation binary
 - - qt5    : Add support for the Qt 5 application and UI 
framework
 + + readline   : Enable support for libreadline, a GNU 
line-editing library that almost everyone wants

 - - smartcard  : Add support for smartcards
 - - tdls   : Add support for Tunneled Direct Link Setup 
(802.11z)
 + + tkip   : Add support for WPA TKIP (deprecated due to 
security flaws in 2009)
 - - uncommon-eap-types : Add support for GPSK, SAKE, GPSK_SHA256, 
IKEV2 and EKE
 - - wep    : Add support for Wired Equivalent Privacy 
(deprecated due to security flaws in 2004)

 - - wps    : Add support for Wi-Fi Protected Setup


emerge --info

Portage 3.0.65 (python 3.12.3-final-0, 
default/linux/amd64/17.1/no-multilib, gcc-13, glibc-2.39-r9, 
6.6.30-gentoo+ x86_64)

=
System uname: 
Linux-6.6.30-gentoo+-x86_64-Intel-R-_Core-TM-_i7-3840QM_CPU_@_2.80GHz-with-glibc2.39

KiB Mem:    16214828 total,   1965812 free
KiB Swap:   33554428 total,  33432572 free
Timestamp of repository gentoo: Sat, 20 Jul 2024 17:15:00 +
Head commit of repository gentoo: aff4faa0924988e635cef587083d3cf848808576
Head commit of repository amarlay: 2a4107e1466105f6f01d94a6a37bb4f858eca42c

Head commit of repository guru: baa8c0cc2f20f0d74145a0ff39ceaac981fd5810

Timestamp of repository palemoon: Fri, 19 Jul 2024 21:03:53 +
Head commit of repository palemoon: 3417bedc5899d74b93f75f1f49785302c31a160b

Head commit of repository unity-gentoo: 

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-21 Thread Frank Steinmetzger
Oopsie, I found this mail in my drafts folder just now, where it’s been 
sitting since the ninth. Perhaps I had to pause writing, but now I can’t 
remember anymore. So I’ll just send it off. ;-)


Am Tue, Jul 09, 2024 at 12:02:47AM +0100 schrieb Michael:

> On Monday, 8 July 2024 21:21:19 BST Frank Steinmetzger wrote:
> > Am Mon, Jul 08, 2024 at 06:26:26PM +0100 schrieb Michael:
> > > Back to the previous topic, I have not yet found a case where changing the
> > > scale by means of the desktop settings, arrives at non-blurred fonts.  The
> > > clearest sharpest fonts are always rendered at the native monitor
> > > resolution, at a 100% scale setting.  Am I missing a trick, or is this to
> > > be expected?
> > That doesn’t really make sense. Fonts are always rendered natively, no
> > matter what size. Except if they are really rendered at 100 % and then the
> > rendered bitmap is scaled by the GPU or somesuch.
> > 
> > Or because their hinting information is limited to a certain size range.
> > This info gives the renderer special knowledge on how to render the glyphs.
> > 
> > Do you have screenshots?
> 
> I attach two screenshots one at 100% and one at 90%.  When viewed on the 
> 1366x768 actual monitor they are worse than what the screenshots have 
> captured.  Perhaps I need to take a photo of the monitor.  Anyway, if you 
> view 
> it on a 1920x1080 monitor you should hopefully see the difference.  The font 
> DPI is 96.

I can see it. I use 2560×1440, but viewing an image pixel-perfect is not 
dependent on the screen’s resolution per se, but on it being run at its 
native resolution. So that one pixel in the image is actually displayed by 
one pixel on the screen without any scaling-induced blurring.

I have no real explanation for the fonts. Do they also get blurry at scales 
bigger than 100 %? The only thing I can say is that I use a font setting of 
slight hinting with no RGB subpixel rendering. The latter means that I don’t 
want the coloured fringes, but prefer greyscale aliasing instead. See my 
screenshot. 96 dpi (100 % scaling), main fonts set to 11 pt.

I used to use full hinting in my early (KDE 3) days, which gives me sharp 
1-pixel-lines, because I was used to the crisp look of non-aliased fonts on 
Windows. But for many years now I’ve been using only slight hinting, so the 
font looks more “real-worldy”, natural and not as computer-clean. I think 
that’s something I picked up during the few times I looked at a mac screen 
or screenshot (I’ve never sat at one for a longer time myself).


PS.: Do you really still use KDE 4 or is it just Oxygen on Plasma 5? I kept 
using Oxygen Icons in Plasma 5. But more and more icons are not updated, so 
I get wrong icons or placeholders, so I bit the bullet and switched to 
breeze. :-/
On second thought, I think I can answer that myself, because the blurred 
icons give it away. With Plasma 6, the global scaling not only affects fonts 
but also the entire UI. I wish this could be disabled, because that is the 
actual reason why I can’t keep on using custom DPI setting any longer. The 
UI just becomes ugly with far too much spacing and those blurry icons.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

Imagine it’s spring time and no tree plays along.


signature.asc
Description: PGP signature


Re: [gentoo-user] sys-apps/init-system-helpers fails. Trying to install needrestart.

2024-07-21 Thread Dale
Michael wrote:
> On Sunday, 21 July 2024 02:38:46 BST Dale wrote:
>> Dale wrote:
>>> Howdy,
>>>
>>> I did my weekly update the other day a little early.  Anyway, I need to
>>> install needrestart but a package fails to build that it depends on. 
>>> This is the short error message. 
>>>
>>>
>>>
>>> root@Gentoo-1 / # cat
>>> /var/log/portage/sys-apps\:init-system-helpers-1.66\:20240720-133504.log
>>>  * Package:sys-apps/init-system-helpers-1.66:0
>>>  * Repository: gentoo
>>>  * USE:abi_x86_64 amd64 elibc_glibc kernel_linux
>>>  * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox
>>>
>> Unpacking source...
>> Unpacking init-system-helpers_1.66.tar.xz to
>>> /var/tmp/portage/sys-apps/init-system-helpers-1.66/work
>>>
>> Source unpacked in
>>> /var/tmp/portage/sys-apps/init-system-helpers-1.66/work
>>>
>> Preparing source in
>>> /var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helper
>>> s
>>> ...
>>>  * Applying revert-openrc-management.patch
>>> ...   
>>>[
>>> ok ]
>>>
>> Source prepared.
>> Configuring source in
>>> /var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helper
>>> s
>>> ...
>>>
>> Source configured.
>> Compiling source in
>>> /var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helper
>>> s
>>> ...
>>>
>> Source compiled.
>> Test phase [not enabled]: sys-apps/init-system-helpers-1.66
>> Install sys-apps/init-system-helpers-1.66 into
>>> /var/tmp/portage/sys-apps/init-system-helpers-1.66/image
>>> Traceback (most recent call last):
>>>   File "/usr/lib/python-exec/python3.12/rst2man", line 8, in 
>>> sys.exit(rst2man())
>>>  ^
>>>   File "/usr/lib/python3.12/site-packages/docutils/core.py", line 760,
>>> in rst2man
>>> rst2something('manpage', 'Unix manual (troff)', 'user/manpage.html')
>>>   File "/usr/lib/python3.12/site-packages/docutils/core.py", line 739,
>>> in rst2something
>>> locale.setlocale(locale.LC_ALL, '')
>>>   File "/usr/lib/python3.12/locale.py", line 615, in setlocale
>>> return _setlocale(category, locale)
>>>
>>> locale.Error: unsupported locale setting
>>>  * ERROR: sys-apps/init-system-helpers-1.66::gentoo failed (install
>>> phase):
>>>  *   Failed to generate man page
>>>  *
>>>  * Call stack:
>>>  * ebuild.sh, line 136:  Called src_install
>>>  *   environment, line 541:  Called die
>>>  * The specific snippet of code:
>>>  *   rst2man man8/service.rst > man8/service.8 || die "Failed to
>>> generate man page";
>>>  *
>>>  * If you need support, post the output of `emerge --info
>>> '=sys-apps/init-system-helpers-1.66::gentoo'`,
>>>  * the complete build log and the output of `emerge -pqv
>>> '=sys-apps/init-system-helpers-1.66::gentoo'`.
>>>  * The complete build log is located at
>>> '/var/log/portage/sys-apps:init-system-helpers-1.66:20240720-133504.log'.
>>>  * For convenience, a symlink to the build log is located at
>>> '/var/tmp/portage/sys-apps/init-system-helpers-1.66/temp/build.log'.
>>>  * The ebuild environment file is located at
>>> '/var/tmp/portage/sys-apps/init-system-helpers-1.66/temp/environment'.
>>>  * Working directory:
>>> '/var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helpe
>>> rs' * S:
>>> '/var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helpe
>>> rs' root@Gentoo-1 / #
>>>
>>>
>>>
>>> It seems to be complaining about rst2man so I thought maybe there was a
>>> linking problem or something and reinstalling the package would help.  I
>>> reinstalled dev-python/docutils but it still fails with the same error. 
>>> I searched forums, BGO and such but no help that I could find.  I also
>>> tried a newer version of init-system-helpers in case the older version
>>> has a flu. 
>>>
>>> On the locale setting.  This is what I have set.  My understanding,
>>> LC_ALL shouldn't be set. 
>>>
>>>
>>> root@Gentoo-1 / # locale
>>> LANG=en_US.utf8
>>> LC_CTYPE="en_US.utf8"
>>> LC_NUMERIC="en_US.utf8"
>>> LC_TIME="en_US.utf8"
>>> LC_COLLATE="en_US.utf8"
>>> LC_MONETARY="en_US.utf8"
>>> LC_MESSAGES="en_US.utf8"
>>> LC_PAPER="en_US.utf8"
>>> LC_NAME="en_US.utf8"
>>> LC_ADDRESS="en_US.utf8"
>>> LC_TELEPHONE="en_US.utf8"
>>> LC_MEASUREMENT="en_US.utf8"
>>> LC_IDENTIFICATION="en_US.utf8"
>>> LC_ALL=
>>> root@Gentoo-1 / #
>>>
>>>
>>>
>>> Anyone have a idea how to fix this?  This is the new rig with merged
>>> /usr and openrc.  In case that matters.  Yes, still named Gentoo-1.  It
>>> needs a better name but just not high on my list right now.  ;-) 
>>>
>>> Dale
>>>
>>> :-)  :-) 
>>>
>>> P. S.  I also got a little thing to put the case on that has wheels. 
>>> It's a tight fit but the case fits on there.  Just gotta be careful when
>>> moving it.  It sits on carpet and mostly wanted to 

Re: [gentoo-user] sys-apps/init-system-helpers fails. Trying to install needrestart.

2024-07-21 Thread Michael
On Sunday, 21 July 2024 02:38:46 BST Dale wrote:
> Dale wrote:
> > Howdy,
> > 
> > I did my weekly update the other day a little early.  Anyway, I need to
> > install needrestart but a package fails to build that it depends on. 
> > This is the short error message. 
> > 
> > 
> > 
> > root@Gentoo-1 / # cat
> > /var/log/portage/sys-apps\:init-system-helpers-1.66\:20240720-133504.log
> >  * Package:sys-apps/init-system-helpers-1.66:0
> >  * Repository: gentoo
> >  * USE:abi_x86_64 amd64 elibc_glibc kernel_linux
> >  * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox
> > 
>  Unpacking source...
>  Unpacking init-system-helpers_1.66.tar.xz to
> > 
> > /var/tmp/portage/sys-apps/init-system-helpers-1.66/work
> > 
>  Source unpacked in
> > 
> > /var/tmp/portage/sys-apps/init-system-helpers-1.66/work
> > 
>  Preparing source in
> > 
> > /var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helper
> > s
> > ...
> >  * Applying revert-openrc-management.patch
> > ...   
> >[
> > ok ]
> > 
>  Source prepared.
>  Configuring source in
> > 
> > /var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helper
> > s
> > ...
> > 
>  Source configured.
>  Compiling source in
> > 
> > /var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helper
> > s
> > ...
> > 
>  Source compiled.
>  Test phase [not enabled]: sys-apps/init-system-helpers-1.66
>  Install sys-apps/init-system-helpers-1.66 into
> > 
> > /var/tmp/portage/sys-apps/init-system-helpers-1.66/image
> > Traceback (most recent call last):
> >   File "/usr/lib/python-exec/python3.12/rst2man", line 8, in 
> > sys.exit(rst2man())
> >  ^
> >   File "/usr/lib/python3.12/site-packages/docutils/core.py", line 760,
> > in rst2man
> > rst2something('manpage', 'Unix manual (troff)', 'user/manpage.html')
> >   File "/usr/lib/python3.12/site-packages/docutils/core.py", line 739,
> > in rst2something
> > locale.setlocale(locale.LC_ALL, '')
> >   File "/usr/lib/python3.12/locale.py", line 615, in setlocale
> > return _setlocale(category, locale)
> >
> > locale.Error: unsupported locale setting
> >  * ERROR: sys-apps/init-system-helpers-1.66::gentoo failed (install
> > phase):
> >  *   Failed to generate man page
> >  *
> >  * Call stack:
> >  * ebuild.sh, line 136:  Called src_install
> >  *   environment, line 541:  Called die
> >  * The specific snippet of code:
> >  *   rst2man man8/service.rst > man8/service.8 || die "Failed to
> > generate man page";
> >  *
> >  * If you need support, post the output of `emerge --info
> > '=sys-apps/init-system-helpers-1.66::gentoo'`,
> >  * the complete build log and the output of `emerge -pqv
> > '=sys-apps/init-system-helpers-1.66::gentoo'`.
> >  * The complete build log is located at
> > '/var/log/portage/sys-apps:init-system-helpers-1.66:20240720-133504.log'.
> >  * For convenience, a symlink to the build log is located at
> > '/var/tmp/portage/sys-apps/init-system-helpers-1.66/temp/build.log'.
> >  * The ebuild environment file is located at
> > '/var/tmp/portage/sys-apps/init-system-helpers-1.66/temp/environment'.
> >  * Working directory:
> > '/var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helpe
> > rs' * S:
> > '/var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helpe
> > rs' root@Gentoo-1 / #
> > 
> > 
> > 
> > It seems to be complaining about rst2man so I thought maybe there was a
> > linking problem or something and reinstalling the package would help.  I
> > reinstalled dev-python/docutils but it still fails with the same error. 
> > I searched forums, BGO and such but no help that I could find.  I also
> > tried a newer version of init-system-helpers in case the older version
> > has a flu. 
> > 
> > On the locale setting.  This is what I have set.  My understanding,
> > LC_ALL shouldn't be set. 
> > 
> > 
> > root@Gentoo-1 / # locale
> > LANG=en_US.utf8
> > LC_CTYPE="en_US.utf8"
> > LC_NUMERIC="en_US.utf8"
> > LC_TIME="en_US.utf8"
> > LC_COLLATE="en_US.utf8"
> > LC_MONETARY="en_US.utf8"
> > LC_MESSAGES="en_US.utf8"
> > LC_PAPER="en_US.utf8"
> > LC_NAME="en_US.utf8"
> > LC_ADDRESS="en_US.utf8"
> > LC_TELEPHONE="en_US.utf8"
> > LC_MEASUREMENT="en_US.utf8"
> > LC_IDENTIFICATION="en_US.utf8"
> > LC_ALL=
> > root@Gentoo-1 / #
> > 
> > 
> > 
> > Anyone have a idea how to fix this?  This is the new rig with merged
> > /usr and openrc.  In case that matters.  Yes, still named Gentoo-1.  It
> > needs a better name but just not high on my list right now.  ;-) 
> > 
> > Dale
> > 
> > :-)  :-) 
> > 
> > P. S.  I also got a little thing to put the case on that has wheels. 
> > It's a tight fit but the case fits on there.  Just gotta be careful when
> > moving it.  It 

Re: [gentoo-user] sys-apps/init-system-helpers fails. Trying to install needrestart.

2024-07-20 Thread Dale
Dale wrote:
> Howdy,
>
> I did my weekly update the other day a little early.  Anyway, I need to
> install needrestart but a package fails to build that it depends on. 
> This is the short error message. 
>
>
>
> root@Gentoo-1 / # cat
> /var/log/portage/sys-apps\:init-system-helpers-1.66\:20240720-133504.log
>  * Package:    sys-apps/init-system-helpers-1.66:0
>  * Repository: gentoo
>  * USE:    abi_x86_64 amd64 elibc_glibc kernel_linux
>  * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox
 Unpacking source...
 Unpacking init-system-helpers_1.66.tar.xz to
> /var/tmp/portage/sys-apps/init-system-helpers-1.66/work
 Source unpacked in
> /var/tmp/portage/sys-apps/init-system-helpers-1.66/work
 Preparing source in
> /var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helpers
> ...
>  * Applying revert-openrc-management.patch
> ...   
>   
> [ ok ]
 Source prepared.
 Configuring source in
> /var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helpers
> ...
 Source configured.
 Compiling source in
> /var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helpers
> ...
 Source compiled.
 Test phase [not enabled]: sys-apps/init-system-helpers-1.66
 Install sys-apps/init-system-helpers-1.66 into
> /var/tmp/portage/sys-apps/init-system-helpers-1.66/image
> Traceback (most recent call last):
>   File "/usr/lib/python-exec/python3.12/rst2man", line 8, in 
>     sys.exit(rst2man())
>  ^
>   File "/usr/lib/python3.12/site-packages/docutils/core.py", line 760,
> in rst2man
>     rst2something('manpage', 'Unix manual (troff)', 'user/manpage.html')
>   File "/usr/lib/python3.12/site-packages/docutils/core.py", line 739,
> in rst2something
>     locale.setlocale(locale.LC_ALL, '')
>   File "/usr/lib/python3.12/locale.py", line 615, in setlocale
>     return _setlocale(category, locale)
>    
> locale.Error: unsupported locale setting
>  * ERROR: sys-apps/init-system-helpers-1.66::gentoo failed (install phase):
>  *   Failed to generate man page
>  *
>  * Call stack:
>  * ebuild.sh, line 136:  Called src_install
>  *   environment, line 541:  Called die
>  * The specific snippet of code:
>  *   rst2man man8/service.rst > man8/service.8 || die "Failed to
> generate man page";
>  *
>  * If you need support, post the output of `emerge --info
> '=sys-apps/init-system-helpers-1.66::gentoo'`,
>  * the complete build log and the output of `emerge -pqv
> '=sys-apps/init-system-helpers-1.66::gentoo'`.
>  * The complete build log is located at
> '/var/log/portage/sys-apps:init-system-helpers-1.66:20240720-133504.log'.
>  * For convenience, a symlink to the build log is located at
> '/var/tmp/portage/sys-apps/init-system-helpers-1.66/temp/build.log'.
>  * The ebuild environment file is located at
> '/var/tmp/portage/sys-apps/init-system-helpers-1.66/temp/environment'.
>  * Working directory:
> '/var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helpers'
>  * S:
> '/var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helpers'
> root@Gentoo-1 / #
>
>
>
> It seems to be complaining about rst2man so I thought maybe there was a
> linking problem or something and reinstalling the package would help.  I
> reinstalled dev-python/docutils but it still fails with the same error. 
> I searched forums, BGO and such but no help that I could find.  I also
> tried a newer version of init-system-helpers in case the older version
> has a flu. 
>
> On the locale setting.  This is what I have set.  My understanding,
> LC_ALL shouldn't be set. 
>
>
> root@Gentoo-1 / # locale
> LANG=en_US.utf8
> LC_CTYPE="en_US.utf8"
> LC_NUMERIC="en_US.utf8"
> LC_TIME="en_US.utf8"
> LC_COLLATE="en_US.utf8"
> LC_MONETARY="en_US.utf8"
> LC_MESSAGES="en_US.utf8"
> LC_PAPER="en_US.utf8"
> LC_NAME="en_US.utf8"
> LC_ADDRESS="en_US.utf8"
> LC_TELEPHONE="en_US.utf8"
> LC_MEASUREMENT="en_US.utf8"
> LC_IDENTIFICATION="en_US.utf8"
> LC_ALL=
> root@Gentoo-1 / #
>
>
>
> Anyone have a idea how to fix this?  This is the new rig with merged
> /usr and openrc.  In case that matters.  Yes, still named Gentoo-1.  It
> needs a better name but just not high on my list right now.  ;-) 
>
> Dale
>
> :-)  :-) 
>
> P. S.  I also got a little thing to put the case on that has wheels. 
> It's a tight fit but the case fits on there.  Just gotta be careful when
> moving it.  It sits on carpet and mostly wanted to get the case off the
> floor for air flow.  Still trying to get used to this smaller keyboard. 
>


Well, no one else seemed to have a better idea so I tried something.  I
set LC_ALL in make.conf.  Guess what, it installed without error with
that set.  During the install, the install guide and I'm pretty sure
someone on this list said it shouldn't be 

Re: [gentoo-user] kernel 6.9 panic....

2024-07-20 Thread Michael
On Saturday, 20 July 2024 18:52:33 BST Alan Grimes wrote:
> Because I did everything precisely the same as I did last time I updated
> my kernel, nothing worked. =|
> 
> Basically the old .config is coppied to the new kernel, and I run it
> with "make -j 60 ; make install modules_install "

Try it in this order and without missing out the make command for the modules 
part:

make -j 60 ; make modules_install ; make install


> Now there are config changes, I just took the default on all changed
> options So far so good,
> 
> I run "grub-mkconfig -o grub.cfg" in the appropriate directory and get
> this garbage:
> 
> Why in the name of the dark lord Baal did grub give different root
> partition ids to the kernels and expect it to work
> 
> Machine is a very heavy duty workstation and quite ornery to get booted
> in the first place. =\
> 
> 6.8
>  }
>  menuentry 'Gentoo GNU/Linux, with Linux 6.8.9-x86_64' --class
> gentoo --class gnu-linux --class gnu --class os $menuentry_id_option
> 'gnulinux-6.8.9-x86_64-advanced-d218b1>
>  load_video
>  if [ "x$grub_platform" = xefi ]; then
>  set gfxpayload=keep
>  fi
>  insmod gzio
>  insmod part_gpt
>  insmod fat
>  search --no-floppy --fs-uuid --set=root BD38-02F6
>  echo'Loading Linux 6.8.9-x86_64 ...'
>  linux   /vmlinuz-6.8.9-x86_64
> root=UUID=d218b143-ba28-4614-b2c8-e93bb8614207 ro
>  echo'Loading initial ramdisk ...'
>  initrd  /amd-uc.img /initramfs-6.8.9-x86_64.img
>  }
> 
> 6.9:
>   {
>  load_video
>  if [ "x$grub_platform" = xefi ]; then
>  set gfxpayload=keep
>  fi
>  insmod gzio
>  insmod part_gpt
>  insmod fat
>  search --no-floppy --fs-uuid --set=root BD38-02F6
>  echo'Loading Linux 6.9.9-x86_64 ...'
>  linux   /vmlinuz-6.9.9-x86_64
> root=PARTUUID=241cc598-140f-42b5-9939-974db55c63e5 ro
>  echo'Loading initial ramdisk ...'
>  initrd  /amd-uc.img
> }



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


[gentoo-user] kernel 6.9 panic....

2024-07-20 Thread Alan Grimes
Because I did everything precisely the same as I did last time I updated 
my kernel, nothing worked. =|


Basically the old .config is coppied to the new kernel, and I run it 
with "make -j 60 ; make install modules_install "


Now there are config changes, I just took the default on all changed 
options So far so good,


I run "grub-mkconfig -o grub.cfg" in the appropriate directory and get 
this garbage:


Why in the name of the dark lord Baal did grub give different root 
partition ids to the kernels and expect it to work


Machine is a very heavy duty workstation and quite ornery to get booted 
in the first place. =\


6.8
    }
    menuentry 'Gentoo GNU/Linux, with Linux 6.8.9-x86_64' --class 
gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-6.8.9-x86_64-advanced-d218b1>

    load_video
    if [ "x$grub_platform" = xefi ]; then
    set gfxpayload=keep
    fi
    insmod gzio
    insmod part_gpt
    insmod fat
    search --no-floppy --fs-uuid --set=root BD38-02F6
    echo    'Loading Linux 6.8.9-x86_64 ...'
    linux   /vmlinuz-6.8.9-x86_64 
root=UUID=d218b143-ba28-4614-b2c8-e93bb8614207 ro

    echo    'Loading initial ramdisk ...'
    initrd  /amd-uc.img /initramfs-6.8.9-x86_64.img
    }

6.9:
 {
    load_video
    if [ "x$grub_platform" = xefi ]; then
    set gfxpayload=keep
    fi
    insmod gzio
    insmod part_gpt
    insmod fat
    search --no-floppy --fs-uuid --set=root BD38-02F6
    echo    'Loading Linux 6.9.9-x86_64 ...'
    linux   /vmlinuz-6.9.9-x86_64 
root=PARTUUID=241cc598-140f-42b5-9939-974db55c63e5 ro

    echo    'Loading initial ramdisk ...'
    initrd  /amd-uc.img
}


--
You can't out-crazy a Democrat.
#EggCrisis  #BlackWinter
White is the new Kulak.
Powers are not rights.




[gentoo-user] Firefox ESR no microphone input

2024-07-20 Thread efeizbudak

Hi everyone,

Lately I have a problem with www-client/firefox-115.12.0:esr where it 
does not pick up audio from my microphone. I'm on a musl system using 
alsa and apulse for firefox.


Here is the emerge --info firefox: https://paste.gentoo.zip/naBQo92V

The funny thing is that arecord works just fine and picks up my 
microphone and I remember firefox having no issues with it either. Can 
anyone push me in the right direction here?


Thank you

--
Efe



[gentoo-user] sys-apps/init-system-helpers fails. Trying to install needrestart.

2024-07-20 Thread Dale
Howdy,

I did my weekly update the other day a little early.  Anyway, I need to
install needrestart but a package fails to build that it depends on. 
This is the short error message. 



root@Gentoo-1 / # cat
/var/log/portage/sys-apps\:init-system-helpers-1.66\:20240720-133504.log
 * Package:    sys-apps/init-system-helpers-1.66:0
 * Repository: gentoo
 * USE:    abi_x86_64 amd64 elibc_glibc kernel_linux
 * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox
>>> Unpacking source...
>>> Unpacking init-system-helpers_1.66.tar.xz to
/var/tmp/portage/sys-apps/init-system-helpers-1.66/work
>>> Source unpacked in
/var/tmp/portage/sys-apps/init-system-helpers-1.66/work
>>> Preparing source in
/var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helpers
...
 * Applying revert-openrc-management.patch
... 

[ ok ]
>>> Source prepared.
>>> Configuring source in
/var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helpers
...
>>> Source configured.
>>> Compiling source in
/var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helpers
...
>>> Source compiled.
>>> Test phase [not enabled]: sys-apps/init-system-helpers-1.66

>>> Install sys-apps/init-system-helpers-1.66 into
/var/tmp/portage/sys-apps/init-system-helpers-1.66/image
Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.12/rst2man", line 8, in 
    sys.exit(rst2man())
 ^
  File "/usr/lib/python3.12/site-packages/docutils/core.py", line 760,
in rst2man
    rst2something('manpage', 'Unix manual (troff)', 'user/manpage.html')
  File "/usr/lib/python3.12/site-packages/docutils/core.py", line 739,
in rst2something
    locale.setlocale(locale.LC_ALL, '')
  File "/usr/lib/python3.12/locale.py", line 615, in setlocale
    return _setlocale(category, locale)
   
locale.Error: unsupported locale setting
 * ERROR: sys-apps/init-system-helpers-1.66::gentoo failed (install phase):
 *   Failed to generate man page
 *
 * Call stack:
 * ebuild.sh, line 136:  Called src_install
 *   environment, line 541:  Called die
 * The specific snippet of code:
 *   rst2man man8/service.rst > man8/service.8 || die "Failed to
generate man page";
 *
 * If you need support, post the output of `emerge --info
'=sys-apps/init-system-helpers-1.66::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=sys-apps/init-system-helpers-1.66::gentoo'`.
 * The complete build log is located at
'/var/log/portage/sys-apps:init-system-helpers-1.66:20240720-133504.log'.
 * For convenience, a symlink to the build log is located at
'/var/tmp/portage/sys-apps/init-system-helpers-1.66/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/sys-apps/init-system-helpers-1.66/temp/environment'.
 * Working directory:
'/var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helpers'
 * S:
'/var/tmp/portage/sys-apps/init-system-helpers-1.66/work/init-system-helpers'
root@Gentoo-1 / #



It seems to be complaining about rst2man so I thought maybe there was a
linking problem or something and reinstalling the package would help.  I
reinstalled dev-python/docutils but it still fails with the same error. 
I searched forums, BGO and such but no help that I could find.  I also
tried a newer version of init-system-helpers in case the older version
has a flu. 

On the locale setting.  This is what I have set.  My understanding,
LC_ALL shouldn't be set. 


root@Gentoo-1 / # locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=
root@Gentoo-1 / #



Anyone have a idea how to fix this?  This is the new rig with merged
/usr and openrc.  In case that matters.  Yes, still named Gentoo-1.  It
needs a better name but just not high on my list right now.  ;-) 

Dale

:-)  :-) 

P. S.  I also got a little thing to put the case on that has wheels. 
It's a tight fit but the case fits on there.  Just gotta be careful when
moving it.  It sits on carpet and mostly wanted to get the case off the
floor for air flow.  Still trying to get used to this smaller keyboard. 



Re: [gentoo-user] Bring back dev-build/bazel ?

2024-07-18 Thread Alexis Praga
Thank you for the advice. Bazelisk seems the way to go as it "is the 
recommended way to install Bazel on Ubuntu, Windows, and macOS" [1].

Alexis

[1] https://bazel.build/install/bazelisk




On Wednesday, July 17th, 2024 at 19:11, Ionen Wolkens  wrote:

> 

> 

> On Wed, Jul 17, 2024 at 09:05:44AM +, Alexis Praga wrote:
> 

> > Dear mailing-list,
> > 

> > dev-build/bazel has been removed last January along with tensorflow from 
> > distribution. While I cannot speak for tensorflow (but it seems a good 
> > idea), would it be doable to add back only bazel ?
> > Maybe as a -bin package to decrease maintainer burden.
> 

> 

> May want to try dev-build/bazelisk, never tried it but from what
> I gather it wraps downloading a suitable version of prebuilt bazel
> and passing arguments to it.
> 

> > I occasionnally have to use at the moment so I would totally understand 
> > that's not a priority.
> > 

> > Thanks,
> > 

> > Alexis
> 

> 

> 

> 

> 

> --
> ionen

signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] chroot: on update I got "mount: /proc: mount failed: Unknown error 5005.,Unable to mark /proc slave: 32"

2024-07-17 Thread Waldo Lemmer
On Wed, Jul 17, 2024, 19:09 Vitaly Zdanevich  wrote:

> My script in the chroot folder:
>
> ```
> mount --rbind /dev dev
> mount --make-rslave dev
> mount -t proc /proc proc
> mount --rbind /sys sys
> mount --make-rslave sys
> mount --rbind /tmp tmp
> mount --bind /run run
>
> mount -o bind /var/db/repos/ var/db/repos/
>
> chroot . /bin/bash
>
> ```
>

The last line chroots into the current working directory, not the directory
where the script is located. Thus, it doesn't matter where your script is
located.

I would suggest adding the following line to the start of your script:

```
cd "$1"
```

Then you can pass the path to your mounted filesystem as a parameter:

```sh
# /mnt/gentoo/chroot.sh /mnt/gentoo/
```

You could also use `dirname "$0"` in your script to get the directory where
your script is located.

>


Re: [gentoo-user] chroot: on update I got "mount: /proc: mount failed: Unknown error 5005.,Unable to mark /proc slave: 32"

2024-07-17 Thread Michael
Hi Vitaly,

On Wednesday, 17 July 2024 18:08:08 BST Vitaly Zdanevich wrote:
> Hi, I did a chroot according to
> https://wiki.gentoo.org/index.php?title=Chroot
> 
> My script in the chroot folder:
> 
> ```
> mount --rbind /dev dev
> mount --make-rslave dev
> mount -t proc /proc proc
> mount --rbind /sys sys
> mount --make-rslave sys
> mount --rbind /tmp tmp
> mount --bind /run run
> 
> mount -o bind /var/db/repos/ var/db/repos/
> 
> chroot . /bin/bash
> 
> ```
[snip ...]

The wiki and the Handbook, explain you need to have a mountpoint for the file 
system in which you are trying to chroot.

For example, the wiki page states:

mkdir /mnt/mychroot  <== this is the mountpoint
cd /mnt/mychroot

or if you are trying to chroot on an existing installation on some block 
device, e.g. say it is partition /dev/sdb3, you would run:

mkdir /mnt/mychroot
mount /dev/sdb3 /mnt/mychroot

Consequently, the mount commands after you mount the OS partition and before 
you chroot become:

cd /mnt/mychroot
mount --rbind /dev /mnt/mychroot/dev
mount --make-rslave /mnt/mychroot/dev
mount -t proc /proc /mnt/mychroot/proc
mount --rbind /sys /mnt/mychroot/sys
mount --make-rslave /mnt/mychroot/sys
mount --rbind /tmp /mnt/mychroot/tmp
rmount --bind /run /mnt/mychroot/run

After the above you can chroot into the mounted filesystem:

chroot /mnt/mychroot /bin/bash


The same approach is followed in the Handbook for a new installation:

https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/
Base#Mounting_the_necessary_filesystems


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


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-17 Thread Dale
Howdy,

A rather large update.  It's got issues still but right now, I'm typing
on the new rig which is not my old main rig, unless something happens to
this new thing.  Old main rig could find itself back again.  Basically,
I'm on the Ryzen thing.  :-D

First, I couldn't open any of my encrypted drives due to missing kernel
options.  Fixed that.  Then openvpn wouldn't work because of missing
kernel drivers.  Fixed that.  Since I started with a new kde config, it
to has issues yet to be banged into submission.  I'm also on a new
keyboard.  Expect some typos until I get used to this dang thing.  The
keys are a little tighter than I'm used too.  I suspect a new keyboard
is on the horizon.  This thing must be made for small kids.  o_o

Right now, only /home hard drive has been moved over.  I still have half
a dozen or so hard drives to move over and get working.  Right now, I'm
banging on KDE configuration stuff.  If it doesn't straighten up soon,
I'm copying the old config files over and it can just deal with that.  o_O

Right now, the second monitor seems to be having a connection issue.  I
had it working then when I pulled the rig out a bit to put in the /home
drive, it went off.  The cables are a bit short.  I think it is pulling
on them enough to disconnect it but not enough for the cable to just
come out completely.  I got cables coming.  They longer and better. 

Another bug I found.  I have 18 virtual desktops.  Yep, 18.  I use Ctrl
F* to switch between #1 to #10.  I can't recall but F11 and F12 is used
by something else.  There is no higher F* keys after that.  They didn't
see me coming.  ROFL  To avoid me having to switch to those, I don't put
anything important there in case I have to use sysreq key to reboot or
the rare occasion it crashes, like running out of memory during a
compile.  Anyway, I found where to set that but some don't work if I
have Firefox on them.  It seems Firefox is watching those keys and
preventing the switch but not doing anything with them either.  That's
kinda bad since sometimes I need to switch to and from those to close
things. 

Well, buggy and lack of configured as it is, it is working.  I'm able to
watch TV and the sound goes to the right place.  I think I can beat the
rest up until it gives in.  Going for a knockout punch, or a hammer.  ;-)

That's it for now.  May have new threads to see if I can get more
setailed help.  Oh, haven't added all the monitors to xorg.conf yet. 
Trying to get some things working first. 

Dale

:-)  :-) 



Re: [gentoo-user] Bring back dev-build/bazel ?

2024-07-17 Thread Ionen Wolkens
On Wed, Jul 17, 2024 at 09:05:44AM +, Alexis Praga wrote:
> Dear mailing-list,
> 
> dev-build/bazel has been removed last January along with tensorflow from 
> distribution. While I cannot speak for tensorflow (but it seems a good idea), 
> would it be doable to add back only bazel ?
> Maybe as a -bin package to decrease maintainer burden.

May want to try dev-build/bazelisk, never tried it but from what
I gather it wraps downloading a suitable version of prebuilt bazel
and passing arguments to it.

> 
> I occasionnally have to use at the moment so I would totally understand 
> that's not a priority.
> 
> Thanks,
> 
> Alexis




-- 
ionen


signature.asc
Description: PGP signature


[gentoo-user] chroot: on update I got "mount: /proc: mount failed: Unknown error 5005.,Unable to mark /proc slave: 32"

2024-07-17 Thread Vitaly Zdanevich
Hi, I did a chroot according to 
https://wiki.gentoo.org/index.php?title=Chroot


My script in the chroot folder:

```
mount --rbind /dev dev
mount --make-rslave dev
mount -t proc /proc proc
mount --rbind /sys sys
mount --make-rslave sys
mount --rbind /tmp tmp
mount --bind /run run

mount -o bind /var/db/repos/ var/db/repos/

chroot . /bin/bash

```

My /root/.bashrc of the new chroot:

```

. /etc/profile
export PS1="(chroot) $PS1"

```

Update command with full output (I never did an update on this chroot):

(chroot) thinkpad-t430 /etc/portage # emerge --ask --update --newuse 
--deep --with-bdeps=y @world


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


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

Calculating dependencies... done!
Dependency resolution took 5.08 s (backtrack: 0/20).

[ebuild   R    ] sys-apps/net-tools-2.10  USE="-ipv6*"
[ebuild UD ] dev-db/sqlite-3.45.3 [3.46.0]
[ebuild   R    ] app-crypt/libb2-0.98.1-r3  USE="openmp*"
[ebuild   R    ] sys-devel/gettext-0.22.4  USE="openmp*"
[ebuild   R    ] sys-libs/pam-1.5.3-r1  USE="filecaps*"
[ebuild   R    ] net-misc/wget-1.24.5  USE="-ipv6*"
[ebuild  N ] app-crypt/rhash-1.4.3  USE="nls ssl -debug -static-libs"
[ebuild  N ] dev-libs/libuv-1.48.0  USE="-verify-sig"
[ebuild  N ] app-arch/libarchive-3.7.4  USE="acl bzip2 e2fsprogs 
iconv lzma xattr zstd -blake2 -expat -lz4 -lzo -nettle -static-libs 
-test -verify-sig"

[ebuild UD ] dev-python/trove-classifiers-2024.5.22 [2024.7.2]
[ebuild   R    ] net-misc/iputils-20240117  USE="filecaps*"
[ebuild  N ] dev-libs/jsoncpp-1.9.5  USE="-doc -test"
[ebuild UD ] dev-python/hatchling-1.24.2 [1.25.0]
[ebuild UD ] dev-python/urllib3-2.2.1 [2.2.2]
[ebuild UD ] dev-python/setuptools-70.0.0 [70.1.1-r1]
[ebuild   R    ] net-misc/dhcpcd-10.0.8  USE="-ipv6*"
[ebuild   R    ] app-portage/portage-utils-0.96.1  USE="openmp*"
[ebuild  N ] dev-build/cmake-3.28.5  USE="ncurses -dap -doc -gui 
-qt6 -test -verify-sig"
[ebuild  N ] net-libs/nghttp2-1.61.0  USE="-debug -hpack-tools 
-jemalloc -static-libs -systemd -test -utils -xml"

[ebuild UD ] net-misc/curl-8.7.1-r4 [8.8.0-r1] USE="http2*"

Would you like to merge these packages? [Yes/No]

>>> Verifying ebuild manifests

>>> Running pre-merge checks for app-crypt/libb2-0.98.1-r3
mount: /proc: mount failed: Unknown error 5005.
Unable to mark /proc slave: 32
 * The ebuild phase 'pretend' has exited unexpectedly. This type of
 * behavior is known to be triggered by things such as failed variable
 * assignments (bug #190128) or bad substitution errors (bug #200313).
 * Normally, before exiting, bash should have displayed an error message
 * above. If bash did not produce an error message above, it's possible
 * that the ebuild has called `exit` when it should have called `die`
 * instead. This behavior may also be triggered by a corrupt bash binary or
 * a hardware problem such as memory or cpu malfunction. If the problem is
 * not reproducible or it appears to occur randomly, then it is likely to
 * be triggered by a hardware problem. If you suspect a hardware problem
 * then you should try some basic hardware diagnostics such as memtest.
 * Please do not report this as a bug unless it is consistently
 * reproducible and you are sure that your bash binary and hardware are
 * functioning properly.

>>> Failed to emerge app-crypt/libb2-0.98.1-r3, Log file:

>>> '/var/tmp/portage/app-crypt/libb2-0.98.1-r3/temp/build.log'

>>> Running pre-merge checks for sys-devel/gettext-0.22.4
mount: /proc: mount failed: Unknown error 5005.
Unable to mark /proc slave: 32
 * The ebuild phase 'pretend' has exited unexpectedly. This type of
 * behavior is known to be triggered by things such as failed variable
 * assignments (bug #190128) or bad substitution errors (bug #200313).
 * Normally, before exiting, bash should have displayed an error message
 * above. If bash did not produce an error message above, it's possible
 * that the ebuild has called `exit` when it should have called `die`
 * instead. This behavior may also be triggered by a corrupt bash binary or
 * a hardware problem such as memory or cpu malfunction. If the problem is
 * not reproducible or it appears to occur randomly, then it is likely to
 * be triggered by a hardware problem. If you suspect a hardware problem
 * then you should try some basic hardware diagnostics such as memtest.
 * Please do not report this as a bug unless it is consistently
 * reproducible and you are sure that your bash binary and hardware are
 * functioning properly.
!!! When you file a bug report, please include the following information:
GENTOO_VM=  CLASSPATH="" JAVA_HOME="/etc/java-config-2/current-system-vm"
JAVACFLAGS="" COMPILER=""
and of course, the output of emerge --info =sys-devel/gettext-0.22.4

>>> Failed to emerge sys-devel/gettext-0.22.4, Log file:

>>> '/var/tmp/portage/sys-devel/gettext-0.22.4/temp/build.log'

 * 

Re: [gentoo-user] Bring back dev-build/bazel ?

2024-07-17 Thread Michael
On Wednesday, 17 July 2024 10:05:44 BST Alexis Praga wrote:
> Dear mailing-list,
> 
> dev-build/bazel has been removed last January along with tensorflow from
> distribution.

It is not in the main tree, but you can install it from the 'vowstar' overlay:

http://gpo.zugaina.org/dev-build/bazel


> While I cannot speak for tensorflow (but it seems a good
> idea),

This package is also available in the 'HomeAssistantRepository':

http://gpo.zugaina.org/sci-libs/tensorflow

See here how to manage individual overlay repositories, if you're not familiar 
with them:

https://wiki.gentoo.org/wiki/Eselect/Repository


> would it be doable to add back only bazel ? Maybe as a -bin package
> to decrease maintainer burden.
> 
> I occasionnally have to use at the moment so I would totally understand
> that's not a priority.
> 
> Thanks,
> 
> Alexis


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


[gentoo-user] Bring back dev-build/bazel ?

2024-07-17 Thread Alexis Praga
Dear mailing-list,

dev-build/bazel has been removed last January along with tensorflow from 
distribution. While I cannot speak for tensorflow (but it seems a good idea), 
would it be doable to add back only bazel ?
Maybe as a -bin package to decrease maintainer burden.

I occasionnally have to use at the moment so I would totally understand that's 
not a priority.

Thanks,

Alexis

signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-16 Thread Eli Schwartz
On 7/15/24 5:54 AM, J. Aho wrote:
> The main issue is that you aren't syncing portage towards the bin
> server, which makes things out of sync and those you will be building a
> lot of the packages instead of fetching the binary files when they are
> built.


As noted earlier, it's more complicated than that. Portage can handle
the case you describe just fine, in the sense that you will be building
a lot of the packages instead of fetching the binary files.

In which case, you don't need to set FEATURES="-getbinpkg" on a per
package basis, since they will simply be built from source anyway.

The problem comes when portage says there *is* a binary package
available, because the index of packages says there is one, then it
tries to download the binary file itself and receives a 404 error. That
causes portage to crash since it doesn't expect the 404.


> If they didn't, then I had the issue as you describe and I had
> discussion about this on the gentoo irc channels, but as back then few
> people used binhosts so they didn't understand the issue and those
> portage don't support to do what you want to do, to filter out new
> ebuilds that don't have a binary package at the binhost, just wait
> another 20 years and then maybe.


I understand where you are coming from :) because I refused to become a
Gentoo user until there were official binhosts.

There is as of 2024 a tracking issue for the bug you described, and with
that public record of what to improve, some progress has been made to
get it to work. I expect it to take significantly less than 20 years to
deploy: the current version of portage stabilized for amd64 causes a
binhost to expose the git commit for gentoo.git that it was built for,
and the plan is that you should be able to have `emerge --sync` just
sync to that revision as announced by the binhost.

I will admit that it took us 5 months from time of reporting until
portage made the progress it has so far, but I'm inclined to blame that
on FOSS software being FOSS and people having other things to do with
their time. Hopefully we'll only need to wait another couple of months
for it to be full solved. :)

Please do consider watching https://bugs.gentoo.org/924772 for further
progress.


-- 
Eli Schwartz



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-16 Thread Peter Humphrey
On Tuesday, 16 July 2024 09:50:00 BST Michael wrote:

> I recall having some trouble with bytemark in the past.

Now you mention it, so do I, but I've been using it for quite a while now with 
no problems.

I suppose servers come and go...

-- 
Regards,
Peter.






Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-16 Thread Michael
On Monday, 15 July 2024 13:36:19 BST Peter Humphrey wrote:
> On Monday, 15 July 2024 10:54:37 BST J. Aho wrote:
> > The main issue is that you aren't syncing portage towards the bin
> > server, which makes things out of sync and those you will be building a
> > lot of the packages instead of fetching the binary files when they are
> > built. One way to come around this issue is that when you sync your
> > portage, wait a day before you check what files to update, this way the
> > binary packages should have been built, but sure it's a pita.
> 
> You're right. I had set the sync-uri to mirror.bytemark.co.uk, which I got
> from the handbook. but I still had GENTOO_MIRRORS="http://
> www.mirrorservice.org/sites/distfiles.gentoo.org/" from an older
> installation.
> 
> I've now set the mirror to bytemark; let's see if that helps.
> 
> Thanks.

I recall having some trouble with bytemark in the past.  A package build time 
dependency portage required to complete an update was not available on 
bytemark and the update failed.  I tried a day later and the same problem came 
up.  A cursory look revealed this mirror to be out of date on a number of 
packages.  Eventually I move to different mirrors and the problem disappeared.


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


Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-15 Thread Peter Humphrey
On Monday, 15 July 2024 10:54:37 BST J. Aho wrote:

> The main issue is that you aren't syncing portage towards the bin
> server, which makes things out of sync and those you will be building a
> lot of the packages instead of fetching the binary files when they are
> built. One way to come around this issue is that when you sync your
> portage, wait a day before you check what files to update, this way the
> binary packages should have been built, but sure it's a pita.

You're right. I had set the sync-uri to mirror.bytemark.co.uk, which I got 
from the handbook. but I still had GENTOO_MIRRORS="http://
www.mirrorservice.org/sites/distfiles.gentoo.org/" from an older installation.

I've now set the mirror to bytemark; let's see if that helps.

Thanks.

-- 
Regards,
Peter.






Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-15 Thread J. Aho

On 13/07/2024 14.50, Peter Humphrey wrote:

Where I live, updates to portage itself usually take longer to appear as a
binary package than as source, so I can't 'getbinpkg'. Therefore I've set:
The main issue is that you aren't syncing portage towards the bin 
server, which makes things out of sync and those you will be building a 
lot of the packages instead of fetching the binary files when they are 
built. One way to come around this issue is that when you sync your 
portage, wait a day before you check what files to update, this way the 
binary packages should have been built, but sure it's a pita.


The proper solution had been that you could sync portage against the 
binhost and that only if the binhost do have two portage that is always 
in par with the packages that has been built. I have my own experience 
of this issue from the time when I had multiple machines at home running 
Gentoo and I had a build environment that built packages for me. I had 
to setup two copies of portage on the build machine, one was the one it 
synced and built against, and then there was the portage version that 
was provided to the clients in the LAN (sadly this has a complication 
for the clients using git instead of rsync), this was only updated after 
a successful build. All the client synced portage against the binhost. 
If they didn't, then I had the issue as you describe and I had 
discussion about this on the gentoo irc channels, but as back then few 
people used binhosts so they didn't understand the issue and those 
portage don't support to do what you want to do, to filter out new 
ebuilds that don't have a binary package at the binhost, just wait 
another 20 years and then maybe.



--

//Aho






Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-15 Thread Dale
Wols Lists wrote:
> On 15/07/2024 07:22, Dale wrote:
>> Is this about the -1 or --oneshot option?
>
> Yes.
>
> Once your system is stable it's a damn good idea :-)
>
> Cheers,
> Wol
>
>


On my recent new rig build, once I installed everything from the world
file from my old system, I added that option to make.conf.  Why that tip
isn't in the install guide surprises me.  A lot of people while trying
to get emerge past a block or something ends up with entries in the
world file that shouldn't be there, especially libs or packages with
versions.  It shouldn't be the default by any means but toward the end
of the install guide, I think it deserves a mention and when to add it. 

Most of my upgrades go fairly smoothly.  One reason for that, nothing is
in the world file unless it really needs to be there.  I can't add
something by mistake. 

Yep.  Good idea.  Sad a lot of people don't know to add that at the
right time. 

Dale

:-)  :-) 



Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-15 Thread Wols Lists

On 15/07/2024 07:22, Dale wrote:

Is this about the -1 or --oneshot option?


Yes.

Once your system is stable it's a damn good idea :-)

Cheers,
Wol



Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-15 Thread Dale
Wol wrote:
> On 14/07/2024 14:15, Peter Humphrey wrote:
>> Yes, I have EMERGE_DEFAULT_OPTS="--jobs=8 --load-average=8
>> --autounmask=n --
>> keep-going  --nospinner"
>>
>> Nothing contentious there, I'd have thought.
>
> I didn't think I had anything contentious - --once-only and that was
> about it. I think that was actually Dale's suggestion - anything I
> emerge will get cleaned away by my next depclean unless I actively
> force it into the world file.
>
> But a load of stuff just wouldn't --update or emerge as a result ...
>
> Cheers,
> Wol
>
>


Is this about the -1 or --oneshot option? 

Dale

:-)  :-) 



Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-14 Thread Eli Schwartz
On 7/14/24 8:04 AM, Peter Humphrey wrote:
> On Sunday, 14 July 2024 07:05:04 BST Eli Schwartz wrote:
> 
>> As a matter of curiosity, why do you need to do any such thing at all?
>>
>> If there is no binary package available for portage yet, then portage
>> will automatically build it from source instead, which is exactly what
>> setting -getbinpkg for it would do. So why bother?
> 
> It doesn't do that here. It tries to fetch the binary and bombs out when it 
> can't be found. Then I have to edit make.conf to update Gentoo, then put it 
> back as it was for the rest of the system.


This indicates that the Packages index on the binhost server doesn't
correspond to the actual packages which are available; it is
broadcasting availability of a new sys-apps/portage binpackage but that
binpackage is not actually present.

It has nothing to do with sys-apps/portage, since if there is a lack of
synchronization here then the specific details of packages does not
matter at all. It just happens, by coincidence, to trigger for you with
the sys-apps/portage package.

This is nominally speaking impossible to happen as it implies the
binhost is simply broken altogether, which of course never happens in
real life because we are all perfect, right?

But actual broken binhosts aside, I'm guessing your real issue is using
a DNS round robin load balancer or similar as your binhost url. You're
getting delivered the Packages index from one server, but actual
*.gpkg.tar requests are being serviced by a different load balancing
machine, and the two aren't precisely in sync.

There are some similar bugs being tracked:

https://bugs.gentoo.org/464906
https://bugs.gentoo.org/831657
https://bugs.gentoo.org/890491
https://bugs.gentoo.org/865845


The default gentoobinhost shipped in stage3 tarballs is
distfiles.gentoo.org, try changing it to a specific mirror and see if
that helps?

-- 
Eli Schwartz



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-14 Thread Dale
Michael wrote:
> On Sunday, 14 July 2024 10:44:30 BST Dale wrote:
>> Well, this was about codec support.  It seems I had none of them
>> available.  I likely enabled more than needed but if it isn't needed, it
>> just ignores them, so I've read anyway.  This is a sort list. 
>>
>> [*] Support initialization patch loading for HD-audio
>> <*> Build Realtek HD-audio codec support
>> <*> Build Analog Devices HD-audio codec support
>> <*> Build IDT/Sigmatel HD-audio codec support
>> <*> Build VIA HD-audio codec support
>> <*> Build HDMI/DisplayPort HD-audio codec support
>> <*> Build Cirrus Logic codec support
>> < > Build Cirrus Logic HDA bridge support
>> <*> Build Conexant HD-audio codec support
>> <*> Build Creative CA0110-IBG codec support
>> <*> Build Creative CA0132 codec support
>> <*> Build C-Media HD-audio codec support
>> <*> Build Silicon Labs 3054 HD-modem codec support
>>
>>
>> With those and a few others, it works.  I suspect the Realtek is the one
>> needed but it may need the HDMI one as well.  I just set the same as on
>> my main rig.  It works.  It seems the card itself had the right driver,
>> just not the bit that tells the card how to process the sound. 
> You can build them as modules, see which of these are loaded successfully and 
> disable the rest.  Some are generic, e.g.
>
>  "Build HDMI/DisplayPort HD-audio codec support"
>
> Say Y or M here to include HDMI and DisplayPort HD-audio codec support in snd-
> hda-intel driver. This includes all AMD/ATI, Intel and Nvidia 
> HDMI/DisplayPort 
> codecs.
>
> Others are more specific to individual OEM chips, like e.g. Realtek with its 
> proprietary audio converter driver.
>

That's true but I wasn't sure which ones I had to have so I just enabled
them all.  I figured if it worked on my main rig, it would work on the
new rig since the audio part is almost identical. That would save me the
trouble of trying to load and remove modules until I figured out which
ones it needed and which ones it didn't.  Basically, it was faster this
way. 

>> It's getting close.  Any day now.  It has been a adventure.  That pesky
>> LG monitor or that HDMI cable caused some issues tho.  I'm looking to
>> buy either 4K or 8K cables next.  Be ready for the future.  ;-)  
> I think the future is DP rather than HDMI, which works with AMD's FreeSync 
> and 
> Nvidia's G-Sync, assuming both card and monitor support this.  You can also 
> chainload monitors from a single DP connection.  However, cable bandwidth and 
> functionality requirements are dictated by the specification of the devices 
> you connect to your card.  A 16K capable DP 2.1, or a 10K capable HDMI 2.1b 
> won't make any difference when you're connecting 1920x1080 (i.e. sub-2K) 
> display panels.  I don't buy cables often, so I tend to buy the highest 
> specification available at the time to future proof, as the monitors and TVs 
> are increasingly made available at higher resolutions and refresh rates.

I think you right.  One reason I was able to get the monitor as cheap as
I did, it is considered old tech now.  Things are moving toward 4k and
such.  I was looking at the 4K cables but then ran up on a cable that is
braided.  Those braided things are tough.  I'd be more worried about
wearing out the connector than damaging the cable.  I could only find
the braided ones in the 8K version.  Still, future proof for me for a
long time to come.  I might get 4k monitor and card the next go around. 
I suspect 8K will be a ways off.  One thing I want to do, replace that
cable that would not work with the new monitor and was used on the LG
monitor when we was arguing with it.  Something funny about that cable. 

It's amazing how much technology changes tho.  What gets me, some things
are a lot faster or bigger but cost is not all that bad given the
improvement.  I still think CPUs are a bit pricey tho. 

I put out 8 Hickory trees this morning.  I also picked my poor sis-n-law
some tomatoes.  I also gave some to a neighbor.  Also making two jars of
pepper sauce today.  I hear my pillow calling me pretty good.  Battery
draining pretty fast.  o_-

Dale

:-)  :-) 



Re: [gentoo-user] ldconfig segfaults after updating to 23.0 profil

2024-07-14 Thread Waldo Lemmer
FYI, Gmail sees this email as spam:

> Be careful with this message
>
> The sender hasn't authenticated this message so Gmail can't verify that
it actually came from them. Avoid clicking links, downloading attachments,
or replying with personal information.

On Thu, Jun 27, 2024 at 9:12 PM Dan Johansson  wrote:

> Hello,
>
> After updating my system to a 23.0 profile,
> default/linux/amd64/23.0/split-usr/desktop/plasma (stable), ldconfig has
> started segfaulting.
>
> Here are the last few lines of "strace ldconfig":
> newfstatat(AT_FDCWD,
> "/usr/lib/rust/lib/librustc_driver-131b866216b2910c.so",
> {st_mode=S_IFREG|0644, st_size=153456592, ...}, 0) = 0
> openat(AT_FDCWD, "/usr/lib/llvm/17/lib",
> O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
> fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> getdents64(3, 0x572629d0 /* 22 entries */, 32768) = 824
> newfstatat(AT_FDCWD, "/usr/lib/llvm/17/lib/libclang.so.17",
> {st_mode=S_IFREG|0755, st_size=17506304, ...}, 0) = 0
> openat(AT_FDCWD, "/usr/lib/llvm/17/lib/libclang.so.17", O_RDONLY) = 4
> fstat(4, {st_mode=S_IFREG|0755, st_size=17506304, ...}) = 0
> mmap(NULL, 17506304, PROT_READ, MAP_SHARED, 4, 0) = 0x7fb6eb2d3000
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
> si_addr=0x7fb6ed37c4dc} ---
> +++ killed by SIGSEGV +++
> Segmentation fault
>
> The file in question (I think), does not look suspicious (I think):
> # ls -pal /usr/lib/llvm/17/lib/libclang.so.17
> /usr/lib/llvm/17/lib/libclang.so.17.0.6
> lrwxrwxrwx 1 root root   18 Jun 25 17:39
> /usr/lib/llvm/17/lib/libclang.so.17 -> libclang.so.17.0.6
> -rwxr-xr-x 1 root root 14893056 Jun 25 17:39
> /usr/lib/llvm/17/lib/libclang.so.17.0.6
>
> The system runs fine (as far as I ca see) but I am a bit nervous about
> rebooting at the moment.
>
> Any suggestions?
>
> Regards,
> --
> Dan Johansson,
> ***
> This message is printed on 100% recycled electrons!
> ***
>
>


Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-14 Thread Wol

On 14/07/2024 14:15, Peter Humphrey wrote:

Yes, I have EMERGE_DEFAULT_OPTS="--jobs=8 --load-average=8 --autounmask=n --
keep-going  --nospinner"

Nothing contentious there, I'd have thought.


I didn't think I had anything contentious - --once-only and that was 
about it. I think that was actually Dale's suggestion - anything I 
emerge will get cleaned away by my next depclean unless I actively force 
it into the world file.


But a load of stuff just wouldn't --update or emerge as a result ...

Cheers,
Wol



Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-14 Thread Peter Humphrey
On Sunday, 14 July 2024 13:22:14 BST Wols Lists wrote:
> On 14/07/2024 13:04, Peter Humphrey wrote:
> > It doesn't do that here. It tries to fetch the binary and bombs out when
> > it can't be found. Then I have to edit make.conf to update Gentoo, then
> > put it back as it was for the rest of the system.
> 
> Do you have PORTAGE_DEFAULT_OPTIONS or whatever it's called set? That's
> caused me similar grief - it messed up my attempts to update my profile,
> it regularly messed up my virtualbox updates, etc etc.

Yes, I have EMERGE_DEFAULT_OPTS="--jobs=8 --load-average=8 --autounmask=n --
keep-going  --nospinner"

Nothing contentious there, I'd have thought.

Then I added this after Arve's advice, and after my problem arose:

EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --usepkg-exclude 'sys-apps/
portage'"

> And if you have to edit various environment variables in make.conf, you
> know you can override them on the command line?
> 
> PORTAGE_DEFAULT_OPTIONS="" emerge virtualbox-modules
> 
> as I had to do ...

Useful reminder; thanks.

-- 
Regards,
Peter.






Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-14 Thread Wols Lists

On 14/07/2024 13:04, Peter Humphrey wrote:

It doesn't do that here. It tries to fetch the binary and bombs out when it
can't be found. Then I have to edit make.conf to update Gentoo, then put it
back as it was for the rest of the system.


Do you have PORTAGE_DEFAULT_OPTIONS or whatever it's called set? That's 
caused me similar grief - it messed up my attempts to update my profile, 
it regularly messed up my virtualbox updates, etc etc.


And if you have to edit various environment variables in make.conf, you 
know you can override them on the command line?


PORTAGE_DEFAULT_OPTIONS="" emerge virtualbox-modules

as I had to do ...

Cheers,
Wol



Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-14 Thread Peter Humphrey
On Sunday, 14 July 2024 07:05:04 BST Eli Schwartz wrote:

> As a matter of curiosity, why do you need to do any such thing at all?
> 
> If there is no binary package available for portage yet, then portage
> will automatically build it from source instead, which is exactly what
> setting -getbinpkg for it would do. So why bother?

It doesn't do that here. It tries to fetch the binary and bombs out when it 
can't be found. Then I have to edit make.conf to update Gentoo, then put it 
back as it was for the rest of the system.

> The only thing that setting -getbinpkg could do is prevent you from
> using a binary on the off chance that it happens to appear faster for you.

That might be so if portage behaved as you said above.

> Note that independent of whether it's useful to exclude this one
> package, the functionality doesn't work. You cannot set per-package
> getbinpkg, this is tracked as https://bugs.gentoo.org/463964

Yes, I saw that from netfab's post.

-- 
Regards,
Peter.






Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-14 Thread Michael
On Sunday, 14 July 2024 10:44:30 BST Dale wrote:
> Michael wrote:
> > On Sunday, 14 July 2024 06:08:27 BST Dale wrote:
> >> I then plugged the TV into the new rig.  KDE saw that right away and
> >> popped up a screen wanting to know what to do.  I just closed it and
> >> went to KDE settings then Display and Monitor section.  I arranged the
> >> monitors like I wanted, several times.  It would pop up a window asking
> >> if I wanted to keep the settings.  Problem is, finding where the mouse
> >> pointer went.  After three or four tries, I finally was able to hit the
> >> Keep button before it reverted back and I had to set it up again.  I did
> >> set it up as described earlier.  It's early on yet but it worked.  Next
> >> is setting up xorg.conf for this.  Gotta add the TV as "Right of" and
> >> all that.
> > 
> > Do you even need an xorg.conf at all, if the Plasma Display settings can
> > set up your monitors/TV reliably, as you want them?
> 
> That is likely true unless KDE has a bad update and won't come up.  I'd
> like my monitors to come up the same way regardless of what GUI I use. 
> I figure xorg.conf is the best way to make sure.  At least as sure as I
> can be anyway.  That said, it's been a long time since I had a bad KDE
> update.  It may have a minor bug or something but it tends to work OK. 

Yes, an xorg.conf set up as you need it would be universal in its effect, 
across different DEs.


> >> Before connecting the TV and all, I tested the audio.  Soundless.
> >> Earlier, I thought it was able to detect nothing plugged into the output
> >> jack.  Well, it appears it just didn't have any devices.  I enabled the
> >> driver the boot media uses and lspci -k showed it as loaded on the new
> >> install.  It seemed to be missing some decode stuff after a bit of
> >> searching.  It so happens, my old rig and the new rig has almost
> >> identical audio chips.  I just pulled up menuconfig on both in a Konsole
> >> and enabled the same things on the new rig that I had on the old rig.
> >> Recompiled the kernel and rebooted.  I have sound to the output jacks
> >> now.  That also likely helped me to have audio on the TV as well.
> > 
> > These links are for MSWindows OS, but corresponding settings to Linux
> > should also work for video cards which include audio processing
> > capability:
> > 
> > https://www.nvidia.com/content/Control-Panel-Help/vLatest/en-us/
> > mergedProjects/nvdsp/To_set_up_digital_audio_on_your_graphics_card.htm
> > 
> > https://www.nvidia.com/content/Control-Panel-Help/vLatest/en-us/
> > mergedProjects/nvdsp/Set_Up_Digital_Audio.htm
> > 
> > https://www.xda-developers.com/set-up-nvidia-high-definition-audio-is-it-w
> > orth-using/
> Well, this was about codec support.  It seems I had none of them
> available.  I likely enabled more than needed but if it isn't needed, it
> just ignores them, so I've read anyway.  This is a sort list. 
> 
> [*] Support initialization patch loading for HD-audio
> <*> Build Realtek HD-audio codec support
> <*> Build Analog Devices HD-audio codec support
> <*> Build IDT/Sigmatel HD-audio codec support
> <*> Build VIA HD-audio codec support
> <*> Build HDMI/DisplayPort HD-audio codec support
> <*> Build Cirrus Logic codec support
> < > Build Cirrus Logic HDA bridge support
> <*> Build Conexant HD-audio codec support
> <*> Build Creative CA0110-IBG codec support
> <*> Build Creative CA0132 codec support
> <*> Build C-Media HD-audio codec support
> <*> Build Silicon Labs 3054 HD-modem codec support
> 
> 
> With those and a few others, it works.  I suspect the Realtek is the one
> needed but it may need the HDMI one as well.  I just set the same as on
> my main rig.  It works.  It seems the card itself had the right driver,
> just not the bit that tells the card how to process the sound. 

You can build them as modules, see which of these are loaded successfully and 
disable the rest.  Some are generic, e.g.

 "Build HDMI/DisplayPort HD-audio codec support"

Say Y or M here to include HDMI and DisplayPort HD-audio codec support in snd-
hda-intel driver. This includes all AMD/ATI, Intel and Nvidia HDMI/DisplayPort 
codecs.

Others are more specific to individual OEM chips, like e.g. Realtek with its 
proprietary audio converter driver.


> It's getting close.  Any day now.  It has been a adventure.  That pesky
> LG monitor or that HDMI cable caused some issues tho.  I'm looking to
> buy either 4K or 8K cables next.  Be ready for the future.  ;-)  

I think the future is DP rather than HDMI, which works with AMD's FreeSync and 
Nvidia's G-Sync, assuming both card and monitor support this.  You can also 
chainload monitors from a single DP connection.  However, cable bandwidth and 
functionality requirements are dictated by the specification of the devices 
you connect to your card.  A 16K capable DP 2.1, or a 10K capable HDMI 2.1b 
won't make any difference when you're connecting 1920x1080 (i.e. sub-2K) 
display panels.  I don't buy cables often, so I 

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-14 Thread Dale
Michael wrote:
> On Sunday, 14 July 2024 06:08:27 BST Dale wrote:
>
>> I then plugged the TV into the new rig.  KDE saw that right away and
>> popped up a screen wanting to know what to do.  I just closed it and
>> went to KDE settings then Display and Monitor section.  I arranged the
>> monitors like I wanted, several times.  It would pop up a window asking
>> if I wanted to keep the settings.  Problem is, finding where the mouse
>> pointer went.  After three or four tries, I finally was able to hit the
>> Keep button before it reverted back and I had to set it up again.  I did
>> set it up as described earlier.  It's early on yet but it worked.  Next
>> is setting up xorg.conf for this.  Gotta add the TV as "Right of" and
>> all that. 
> Do you even need an xorg.conf at all, if the Plasma Display settings can set 
> up your monitors/TV reliably, as you want them?
>

That is likely true unless KDE has a bad update and won't come up.  I'd
like my monitors to come up the same way regardless of what GUI I use. 
I figure xorg.conf is the best way to make sure.  At least as sure as I
can be anyway.  That said, it's been a long time since I had a bad KDE
update.  It may have a minor bug or something but it tends to work OK. 


>> I did run into a error when trying to copy a couple video test files
>> from a USB stick to the desktop.  The error was this:   'The file or
>> folder message recipient disconnected from message bus without replying
>> does not exist.'  It was confusing to say the least.  It reads like it
>> went through a translator or something.  I checked to make sure
>> everything was mounted rw correctly, checked permissions and such. 
>> Everything was set correctly.  Did a search and dug out a thread on the
>> forums.  It said the kernel had to have the Fuse driver enabled.  I'm
>> not sure why but OK, I enabled and rebuilt the kernel.  When I booted
>> the new kernel, I could copy files over.  Weird but it works, cool.  :-) 
> https://bugs.kde.org/show_bug.cgi?id=473733
>

Odd, that bug report didn't show up when I searched with Duck. 
Sometimes I wonder about search engines.  Sometimes I think they assume
to much. 


>> Before connecting the TV and all, I tested the audio.  Soundless. 
>> Earlier, I thought it was able to detect nothing plugged into the output
>> jack.  Well, it appears it just didn't have any devices.  I enabled the
>> driver the boot media uses and lspci -k showed it as loaded on the new
>> install.  It seemed to be missing some decode stuff after a bit of
>> searching.  It so happens, my old rig and the new rig has almost
>> identical audio chips.  I just pulled up menuconfig on both in a Konsole
>> and enabled the same things on the new rig that I had on the old rig. 
>> Recompiled the kernel and rebooted.  I have sound to the output jacks
>> now.  That also likely helped me to have audio on the TV as well. 
> These links are for MSWindows OS, but corresponding settings to Linux should 
> also work for video cards which include audio processing capability:
>
> https://www.nvidia.com/content/Control-Panel-Help/vLatest/en-us/
> mergedProjects/nvdsp/To_set_up_digital_audio_on_your_graphics_card.htm
>
> https://www.nvidia.com/content/Control-Panel-Help/vLatest/en-us/
> mergedProjects/nvdsp/Set_Up_Digital_Audio.htm
>
> https://www.xda-developers.com/set-up-nvidia-high-definition-audio-is-it-worth-using/
>

Well, this was about codec support.  It seems I had none of them
available.  I likely enabled more than needed but if it isn't needed, it
just ignores them, so I've read anyway.  This is a sort list. 

[*] Support initialization patch loading for HD-audio
<*> Build Realtek HD-audio codec support
<*> Build Analog Devices HD-audio codec support
<*> Build IDT/Sigmatel HD-audio codec support
<*> Build VIA HD-audio codec support
<*> Build HDMI/DisplayPort HD-audio codec support
<*> Build Cirrus Logic codec support
< > Build Cirrus Logic HDA bridge support
<*> Build Conexant HD-audio codec support
<*> Build Creative CA0110-IBG codec support
<*> Build Creative CA0132 codec support
<*> Build C-Media HD-audio codec support
<*> Build Silicon Labs 3054 HD-modem codec support


With those and a few others, it works.  I suspect the Realtek is the one
needed but it may need the HDMI one as well.  I just set the same as on
my main rig.  It works.  It seems the card itself had the right driver,
just not the bit that tells the card how to process the sound. 

>> I haven't posted much but I been busy.  I also checked the serial
>> numbers of the monitors.  One ends in 231 while other ends in 240.  They
>> are 9 digits apart.  About as identical as one can get.  ;-) 
> You can compare the EDIDs in Xorg.0.conf to see if they are the same.
>
> It seems you're making good progress with your new PC & monitors.  :-)


Yep.  I think the doctors refer to it as fatigue but basically, I do a
little, take a nap.  It's related to my health issues.  Some days, I'm
like that meme with the guy beating a 

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-14 Thread Michael
On Sunday, 14 July 2024 06:08:27 BST Dale wrote:

> I then plugged the TV into the new rig.  KDE saw that right away and
> popped up a screen wanting to know what to do.  I just closed it and
> went to KDE settings then Display and Monitor section.  I arranged the
> monitors like I wanted, several times.  It would pop up a window asking
> if I wanted to keep the settings.  Problem is, finding where the mouse
> pointer went.  After three or four tries, I finally was able to hit the
> Keep button before it reverted back and I had to set it up again.  I did
> set it up as described earlier.  It's early on yet but it worked.  Next
> is setting up xorg.conf for this.  Gotta add the TV as "Right of" and
> all that. 

Do you even need an xorg.conf at all, if the Plasma Display settings can set 
up your monitors/TV reliably, as you want them?


> I did run into a error when trying to copy a couple video test files
> from a USB stick to the desktop.  The error was this:   'The file or
> folder message recipient disconnected from message bus without replying
> does not exist.'  It was confusing to say the least.  It reads like it
> went through a translator or something.  I checked to make sure
> everything was mounted rw correctly, checked permissions and such. 
> Everything was set correctly.  Did a search and dug out a thread on the
> forums.  It said the kernel had to have the Fuse driver enabled.  I'm
> not sure why but OK, I enabled and rebuilt the kernel.  When I booted
> the new kernel, I could copy files over.  Weird but it works, cool.  :-) 

https://bugs.kde.org/show_bug.cgi?id=473733


> Before connecting the TV and all, I tested the audio.  Soundless. 
> Earlier, I thought it was able to detect nothing plugged into the output
> jack.  Well, it appears it just didn't have any devices.  I enabled the
> driver the boot media uses and lspci -k showed it as loaded on the new
> install.  It seemed to be missing some decode stuff after a bit of
> searching.  It so happens, my old rig and the new rig has almost
> identical audio chips.  I just pulled up menuconfig on both in a Konsole
> and enabled the same things on the new rig that I had on the old rig. 
> Recompiled the kernel and rebooted.  I have sound to the output jacks
> now.  That also likely helped me to have audio on the TV as well. 

These links are for MSWindows OS, but corresponding settings to Linux should 
also work for video cards which include audio processing capability:

https://www.nvidia.com/content/Control-Panel-Help/vLatest/en-us/
mergedProjects/nvdsp/To_set_up_digital_audio_on_your_graphics_card.htm

https://www.nvidia.com/content/Control-Panel-Help/vLatest/en-us/
mergedProjects/nvdsp/Set_Up_Digital_Audio.htm

https://www.xda-developers.com/set-up-nvidia-high-definition-audio-is-it-worth-using/


> I haven't posted much but I been busy.  I also checked the serial
> numbers of the monitors.  One ends in 231 while other ends in 240.  They
> are 9 digits apart.  About as identical as one can get.  ;-) 

You can compare the EDIDs in Xorg.0.conf to see if they are the same.

It seems you're making good progress with your new PC & monitors.  :-)


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


Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-14 Thread netfab
Le 14/07/24 à 02:18, Peter Humphrey a tapoté :
> It works, but what's wrong with the way I tried it?

Here is the explanation :

https://bugs.gentoo.org/463964

> Currently, FEATURES=getbinpkg only works as a global setting.

And from :

https://forums.gentoo.org/viewtopic-t-1166963.html

> FEATURES are not fully supported in package.env as they can cause
> circular effects (e.g. getbinpkg may cause a different version to get
> selected, which can result in the package.env entry no longer being
> applicable).





Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-14 Thread Dale
Eli Schwartz wrote:
> On 7/13/24 8:42 AM, Peter Humphrey wrote:
>> Hello list,
>>
>> Where I live, updates to portage itself usually take longer to appear as a 
>> binary package than as source, so I can't 'getbinpkg'. Therefore I've set:
>>
>> # cat /etc/portage/env/nobinpkg.conf
>> FEATURES="${FEATURES} -getbinpkg"
>>
>> # cat /etc/portage/package.env
>> sys-apps/portage nobinpkg.conf
>>
>> But still portage wants to fetch the binary.
>>
>> What am I doing wrong?
> As a matter of curiosity, why do you need to do any such thing at all?
>
> If there is no binary package available for portage yet, then portage
> will automatically build it from source instead, which is exactly what
> setting -getbinpkg for it would do. So why bother?
>
> The only thing that setting -getbinpkg could do is prevent you from
> using a binary on the off chance that it happens to appear faster for you.
>
>
> Note that independent of whether it's useful to exclude this one
> package, the functionality doesn't work. You cannot set per-package
> getbinpkg, this is tracked as https://bugs.gentoo.org/463964
>
>
> -- Eli Schwartz

That's actually why he wants to do that.  It seems for some reason,
portage shows up as a source long before the binary packages do.  So, he
wants to make a exception for portage so he can just build it himself
locally.  Given it likely doesn't take long to build from source anyway,
why not.  I'd suspect tho that most packages show up as source before
binary packages do tho.  After all, one has to have the source to build
the binary ones.  I guess maybe portage lags behind further than others
or something, at least for the OP anyway. 

I never did the binary thing tho.  When compiles start taking to long,
time to build a faster rig.  :-D  Some devices tho, like Raspberry Pis,
don't have that option. 

Dale

:-)  :-) 


Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-14 Thread Eli Schwartz
On 7/13/24 8:42 AM, Peter Humphrey wrote:
> Hello list,
> 
> Where I live, updates to portage itself usually take longer to appear as a 
> binary package than as source, so I can't 'getbinpkg'. Therefore I've set:
> 
> # cat /etc/portage/env/nobinpkg.conf
> FEATURES="${FEATURES} -getbinpkg"
> 
> # cat /etc/portage/package.env
> sys-apps/portage nobinpkg.conf
> 
> But still portage wants to fetch the binary.
> 
> What am I doing wrong?


As a matter of curiosity, why do you need to do any such thing at all?

If there is no binary package available for portage yet, then portage
will automatically build it from source instead, which is exactly what
setting -getbinpkg for it would do. So why bother?

The only thing that setting -getbinpkg could do is prevent you from
using a binary on the off chance that it happens to appear faster for you.


Note that independent of whether it's useful to exclude this one
package, the functionality doesn't work. You cannot set per-package
getbinpkg, this is tracked as https://bugs.gentoo.org/463964


-- 
Eli Schwartz



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-13 Thread Dale
Michael wrote:
> On Thursday, 11 July 2024 07:23:58 BST Dale wrote:
>> Michael wrote:
>>> As far as I know SDDM is using the file(s) in /usr/share/sddm/scripts/ to
>>> start a login GUI.  I haven't looked into how far can these be tweaked for
>>> a dual monitor setup and if they even have a 'primary' monitor concept.
>> I've never really looked into it either.  I mentioned it because it
>> seems something has changed.  On my old rig, it seems to have kept some
>> setting somewhere but on new installs, it uses a new setting which we
>> may both like better.  Luckily one of my TVs is in the same room so I
>> can see the screen.  If however, you have a second monitor that you
>> can't see, it may be worth looking into and setting it to the new way. 
>> It could be that someone reading this long thread would also like to
>> know to do the same.  ;-)
> Hmm ... on a system here running with two monitors, the SDDM passwd field is 
> only showing being typed in on the right hand side (the secondary) monitor.  
> The primary monitor passwd field remains empty, unless I click on it before I 
> start typing.  There is no custom SDDM config and no xorg.conf in this 
> system.  
> :-/
>

I've been watching this some more each time I boot.  When I hit the
power button and the BIOS screen comes up, only the main monitor, the
first or original monitor, or monitor connected to the number #1 port on
bracket, powers up and shows anything.  The second monitor remains off. 
The second monitor remains off until SDDM comes up for a password which
then powers on the second monitor.  When the second monitor powers up,
it appears to be a clone of monitor 1.  If I type in the password, the
dots appear on BOTH monitors. 

I haven't tested this in a while but before I added DM to the default
runlevel, if I switched to a console, Ctrl Alt F1 for example, to try a
different setting or something *after* SDDM came up even once, then both
monitors showed the same thing, they would appear as clones.  If I typed
in a command, it would show on both monitors.  Once the second monitor
powered up, it stayed on the whole time.  It seems SDDM cuts it on but
after that, it stays on even if a clone of monitor 1 in a console. 

My main rig behaves differently.  I think during the install, there is a
different config for how monitors are handled and when they are powered
on.  On my old rig, it behaves as you describe.  On the new rig, like
described above.  Honestly, I like the new way except I wish the second
monitor would come on with the main monitor as clones when the BIOS
screen comes up.  I can live with it tho.  It does come on when it is
able to really show something. 

I suspect, if you did a fresh install, you would see the same behavior I
see with the new rig.  The way my old rig and your rig works is likely
left over from the old default way it was set up.  I don't know if that
is set up with SDDM, Xorg or what.  I think emerge has a --noconf or
something option that updates config files even if they wouldn't
otherwise.  That to might overwrite the old way with the new way.  If
one only knew what package set that to work that way tho.  The new rig
seems to have a new default way to handle the monitors.


>> I found the man page and another web page with a ton of info on
>> options.  Link below in case others want to bookmark it.  Some of them I
>> have no idea what they do.  Even their description for some settings
>> makes no sense since the terms used are things I never heard of.  I
>> doubt I need those anyway, thank goodness.  Anyway.  I been playing with
>> this thing a bit.  I made a simple change in xorg.conf just to see if it
>> worked or not without changing anything else.  I added this to the
>> options for the second monitor:
>>
>>
>> Option  "Above" "DP-3"
>>
>>
>> I'll see how that works.  May try another GUI to, Fluxbox or something. 
>> For some reason tho, the port numbers are still odd, consistent but
>> odd.  Primary monitor is plugged into the lowest port, the one with #1
>> stamped on the bracket.  It sees it as DP-3 tho.  Even more odd, the
>> second monitor is DP-1, which is marked as port #2 on the bracket.  I
>> can't make heads or tails of that mess.  o_O
> Yes, this numbering incongruity between physical and logical ports is quite  
> strange.  o_O
>

I'm done trying to figure out that weirdness.  ROFL  Maybe it takes
after me.  ROFLMBO 


>> I did change how I plan to lay out the monitors tho.  From the primary
>> monitor as a starting point, second monitor that I use for handling
>> large volume of files and such will be above the primary monitor.  My TV
>> will be to the right of the Primary monitor.  The reason for that is
>> mostly the physical layout.  The monitor stand came in and I'll be
>> putting the primary monitor on the bottom and second monitor on top of
>> it.  The TV can just go anywhere config wise but it has been to the
>> right for so long, when I need my mouse pointer over there, habit 

Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-13 Thread Peter Humphrey
On Saturday, 13 July 2024 15:49:00 BST Peter Humphrey wrote:
> On Saturday, 13 July 2024 14:18:09 BST Arve Barsnes wrote:
--->8
> > I don't know what you're doing wrong, but FEATURES is an additive
> > variable, so adding the ${FEATURES} in there is not necessary.
> 
> I've tried it without that parenthesis but with no difference.
> 
> > An alternative might be adding it to emerge default opts in make.conf:
> > 
> > EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --usepkg-exclude
> > 'sys-apps/portage'"
> 
> Interesting. I hadn't seen that construction before; I'll try it.

It works, but what's wrong with the way I tried it?

-- 
Regards,
Peter.






Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-13 Thread Peter Humphrey
On Saturday, 13 July 2024 14:18:09 BST Arve Barsnes wrote:
> On Sat, 13 Jul 2024 at 14:42, Peter Humphrey  
wrote:
> > Hello list,
> > 
> > Where I live, updates to portage itself usually take longer to appear as a
> > binary package than as source, so I can't 'getbinpkg'. Therefore I've set:
> > 
> > # cat /etc/portage/env/nobinpkg.conf
> > FEATURES="${FEATURES} -getbinpkg"
> > 
> > # cat /etc/portage/package.env
> > sys-apps/portage nobinpkg.conf
> > 
> > But still portage wants to fetch the binary.
> > 
> > What am I doing wrong?
> 
> I don't know what you're doing wrong, but FEATURES is an additive
> variable, so adding the ${FEATURES} in there is not necessary.

I've tried it without that parenthesis but with no difference.

> An alternative might be adding it to emerge default opts in make.conf:
> 
> EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --usepkg-exclude
> 'sys-apps/portage'"

Interesting. I hadn't seen that construction before; I'll try it.

Thanks Arve.

-- 
Regards,
Peter.






Re: [gentoo-user] sys-apps/portage and binary packages

2024-07-13 Thread Arve Barsnes
On Sat, 13 Jul 2024 at 14:42, Peter Humphrey  wrote:
>
> Hello list,
>
> Where I live, updates to portage itself usually take longer to appear as a
> binary package than as source, so I can't 'getbinpkg'. Therefore I've set:
>
> # cat /etc/portage/env/nobinpkg.conf
> FEATURES="${FEATURES} -getbinpkg"
>
> # cat /etc/portage/package.env
> sys-apps/portage nobinpkg.conf
>
> But still portage wants to fetch the binary.
>
> What am I doing wrong?

I don't know what you're doing wrong, but FEATURES is an additive
variable, so adding the ${FEATURES} in there is not necessary.

An alternative might be adding it to emerge default opts in make.conf:

EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --usepkg-exclude 'sys-apps/portage'"

Regards,
Arve



[gentoo-user] sys-apps/portage and binary packages

2024-07-13 Thread Peter Humphrey
Hello list,

Where I live, updates to portage itself usually take longer to appear as a 
binary package than as source, so I can't 'getbinpkg'. Therefore I've set:

# cat /etc/portage/env/nobinpkg.conf
FEATURES="${FEATURES} -getbinpkg"

# cat /etc/portage/package.env
sys-apps/portage nobinpkg.conf

But still portage wants to fetch the binary.

What am I doing wrong?

-- 
Regards,
Peter.






Re: [gentoo-user] IRC: "Error: You are banned from this server"

2024-07-13 Thread Michael
On Saturday, 13 July 2024 02:26:41 BST Ionen Wolkens wrote:
> On Sat, Jul 13, 2024 at 04:11:05AM +0400, Vitaly Zdanevich wrote:
> > We had nothing bad in our conversations...
> 
> From the whole server, not a channel? Don't know what happened but it
> wouldn't be Gentoo-specific then given Gentoo doesn't run IRC servers
> nor is part of the Libera staff.

According to the Libera FAQs:

"The server says I am banned! Why?

If you are unable to connect to the network and have received a message that 
you are banned, first ensure that you are using SASL as sometimes we need to 
restrict some IPs to require the SASL authentication method. This requires you 
to have registered an account already. Use another internet connection to make 
an account first, if you’re unable to connect on your regular internet 
connection.

If you are still unable to connect, or if you get banned again once you do 
connect, you can enquire about the ban by sending an email to us at 
b...@libera.chat."

https://libera.chat/guides/faq#the-server-says-i-am-banned-why

It's probably a temporary ban, perhaps you were caught into some geographic IP 
range during a DDoS.


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


Re: [gentoo-user] IRC: "Error: You are banned from this server"

2024-07-12 Thread Ionen Wolkens
On Sat, Jul 13, 2024 at 04:11:05AM +0400, Vitaly Zdanevich wrote:
> We had nothing bad in our conversations...

From the whole server, not a channel? Don't know what happened but it
wouldn't be Gentoo-specific then given Gentoo doesn't run IRC servers
nor is part of the Libera staff.
-- 
ionen


signature.asc
Description: PGP signature


[gentoo-user] IRC: "Error: You are banned from this server"

2024-07-12 Thread Vitaly Zdanevich

We had nothing bad in our conversations...


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-11 Thread Michael
On Thursday, 11 July 2024 07:23:58 BST Dale wrote:
> Michael wrote:

> > As far as I know SDDM is using the file(s) in /usr/share/sddm/scripts/ to
> > start a login GUI.  I haven't looked into how far can these be tweaked for
> > a dual monitor setup and if they even have a 'primary' monitor concept.
> I've never really looked into it either.  I mentioned it because it
> seems something has changed.  On my old rig, it seems to have kept some
> setting somewhere but on new installs, it uses a new setting which we
> may both like better.  Luckily one of my TVs is in the same room so I
> can see the screen.  If however, you have a second monitor that you
> can't see, it may be worth looking into and setting it to the new way. 
> It could be that someone reading this long thread would also like to
> know to do the same.  ;-)

Hmm ... on a system here running with two monitors, the SDDM passwd field is 
only showing being typed in on the right hand side (the secondary) monitor.  
The primary monitor passwd field remains empty, unless I click on it before I 
start typing.  There is no custom SDDM config and no xorg.conf in this system.  
:-/


> I found the man page and another web page with a ton of info on
> options.  Link below in case others want to bookmark it.  Some of them I
> have no idea what they do.  Even their description for some settings
> makes no sense since the terms used are things I never heard of.  I
> doubt I need those anyway, thank goodness.  Anyway.  I been playing with
> this thing a bit.  I made a simple change in xorg.conf just to see if it
> worked or not without changing anything else.  I added this to the
> options for the second monitor:
> 
> 
> Option  "Above" "DP-3"
> 
> 
> I'll see how that works.  May try another GUI to, Fluxbox or something. 
> For some reason tho, the port numbers are still odd, consistent but
> odd.  Primary monitor is plugged into the lowest port, the one with #1
> stamped on the bracket.  It sees it as DP-3 tho.  Even more odd, the
> second monitor is DP-1, which is marked as port #2 on the bracket.  I
> can't make heads or tails of that mess.  o_O

Yes, this numbering incongruity between physical and logical ports is quite  
strange.  o_O


> I did change how I plan to lay out the monitors tho.  From the primary
> monitor as a starting point, second monitor that I use for handling
> large volume of files and such will be above the primary monitor.  My TV
> will be to the right of the Primary monitor.  The reason for that is
> mostly the physical layout.  The monitor stand came in and I'll be
> putting the primary monitor on the bottom and second monitor on top of
> it.  The TV can just go anywhere config wise but it has been to the
> right for so long, when I need my mouse pointer over there, habit makes
> me push the mouse to the right.  It's as good a place as any. 
> 
> At first, I had the second monitor to the right of primary but then it
> hit me, dragging the mouse pointer, and files, to the right to go up to
> the top monitor seems kinda odd.  Plus, for a long time now, the TV has
> been there on the right.  I rearranged things a bit.  Given the physical
> layout, it makes more sense this way.  While I'm thinking on this.  I
> may turn off the second monitor at times.  Should I add a option to
> xorg.conf to make sure it doesn't go weird on me?  I wouldn't want it to
> move my TV location for example.  I'd just want it to power off but not
> affect anything else.  I'd close all the apps first tho.  I'd also like
> it to have the right settings if it has been off a while and I turn it
> on to use it.  I'm not sure how hotpluggable monitors are. 

I have not observed any discrepancy when a monitor is switched off/on at the 
time of booting or thereafter, but I've used the Plasma Display settings to 
configure the monitors position and in any case here the desktop is on Plasma-
Wayland.  Therefore your experience may differ.




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


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-11 Thread Dale
Michael wrote:
> On Wednesday, 10 July 2024 12:44:28 BST Dale wrote:
>
>> It sounds like you recommend me using xorg.conf and not xrandr.  I was
>> thinking that using both would also cause a clash.  Basically, I need
>> one tool to do this.  That's why I picked xorg.conf for long term,
>> xrandr is just for now or a second option.  I may comment that command
>> and reboot.  See if it is the xorg.conf file doing the work or xrandr. 
> I recommend using whichever tool does the job best, for your specific needs.  
> Normally, sections for xorg.conf can be used for special input and display 
> configurations, when the default configuration (running without a xorg.conf) 
> will not do.
>
> The xranrd command is there to manually interface in real time with the RandR 
> extension of the X11 API and change some settings to make sure they suit your 
> preferences.  You can, if you want to, script it and run it every time X 
> starts, to change the default settings.
>
> If you are always using Plasma, then it may be convenient to use neither an 
> xorg.conf, nor xrandr and instead use the 'Plasma > SystemSettings > Display 
> and Monitor' GUI to configure your desktop setup.
>
> Any of the above three options should be able to do the job, but some may be 
> more reliable than others.  I found out whenever Plasma was being upgraded to 
> a new major/minor version the layout on a dual monitor setup running on X was 
> all over the place.  I moved that system over to Wayland and I had no more 
> complaints from users about a displaced toolbar, or reversed monitor layout 
> and the like.  YMMV.
>

I've read wayland has improved a lot.  A year or more ago I was reading
about people finding bugs and such and some even saying it wasn't usable
in a lot of situations.  Thing is, it was new and that is to be
expected.  Over time, it seems to have improved.  Some people, like you,
say it has advantages to use it now and sometimes even works better.
Once I get things working well, I just may give it a shot.  It seems
things are moving in that direction anyway. 


>> I think we talked about this maybe off list.  On my old machine, when
>> sddm comes up, the password field on the second monitor shows the dots,
>> TV in my case.  On the new machine, both monitors show the dots for the
>> password.  I'm not sure what is different tho.  It did that even before
>> I set the primary option.  I like it that way myself but makes me
>> curious why my main rig is different.  It seems the new rig sends the
>> same screen to both monitors.  Once logged into KDE, it splits into two
>> monitors.  My main rig it seems is always two separate screens. 
> As far as I know SDDM is using the file(s) in /usr/share/sddm/scripts/ to 
> start a login GUI.  I haven't looked into how far can these be tweaked for a 
> dual monitor setup and if they even have a 'primary' monitor concept.
>

I've never really looked into it either.  I mentioned it because it
seems something has changed.  On my old rig, it seems to have kept some
setting somewhere but on new installs, it uses a new setting which we
may both like better.  Luckily one of my TVs is in the same room so I
can see the screen.  If however, you have a second monitor that you
can't see, it may be worth looking into and setting it to the new way. 
It could be that someone reading this long thread would also like to
know to do the same.  ;-)


>> I got some things going on.  I'll read the email closer later and make
>> some changes.  I'll post back then.  Oh, so far, it shows several
>> packages headed in the right direction.  The monitor stand left a small
>> hub and when it leaves there, it almost always gets delivered that day. 
>> So, I may get the monitor stand today.  The new /home hard drive is on
>> the right path too.  I'm expecting quite a lot of packages.  While
>> proofing this, got text from USPS that stand and several other packages
>> are out for delivery.  UPS updates a little later. 
>>
>> Oh, in /etc/X11/xorg.conf.d/ when the files are numbered, does it read
>> them from low to high?  
> Yes.
>
>> If I set a option in one file but set the same
>> option differently in another file, which one does it apply?  Or does it
>> not apply either? 
> First the lower numbered file, then the higher numbered file (see man run-
> parts).  Also see explanation in the URL below.
>
>> Thanks for the info.  :-D  Will work on it shortly. 
>>
>> Dale
>>
>> :-)  :-) 
> https://wiki.gentoo.org/wiki/Xorg.conf
>
> The separate files in /etc/X11/xorg.conf.d/ are meant to break things up and 
> make it easier to check, add, or take out sections.  Configuration files are 
> read in numeric order and sequentially, i.e. 10-monitor.conf will be read and 
> applied before 20-monitor.conf, or 30-something-else.conf.  Files will be 
> read 
> in alphabetic order if they are not prefixed by a number.
>
> Note, as the above URL points out, if you have a /etc/X11/xorg.conf file it 
> will take precedence over any 

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-10 Thread Michael
On Wednesday, 10 July 2024 12:44:28 BST Dale wrote:

> It sounds like you recommend me using xorg.conf and not xrandr.  I was
> thinking that using both would also cause a clash.  Basically, I need
> one tool to do this.  That's why I picked xorg.conf for long term,
> xrandr is just for now or a second option.  I may comment that command
> and reboot.  See if it is the xorg.conf file doing the work or xrandr. 

I recommend using whichever tool does the job best, for your specific needs.  
Normally, sections for xorg.conf can be used for special input and display 
configurations, when the default configuration (running without a xorg.conf) 
will not do.

The xranrd command is there to manually interface in real time with the RandR 
extension of the X11 API and change some settings to make sure they suit your 
preferences.  You can, if you want to, script it and run it every time X 
starts, to change the default settings.

If you are always using Plasma, then it may be convenient to use neither an 
xorg.conf, nor xrandr and instead use the 'Plasma > SystemSettings > Display 
and Monitor' GUI to configure your desktop setup.

Any of the above three options should be able to do the job, but some may be 
more reliable than others.  I found out whenever Plasma was being upgraded to 
a new major/minor version the layout on a dual monitor setup running on X was 
all over the place.  I moved that system over to Wayland and I had no more 
complaints from users about a displaced toolbar, or reversed monitor layout 
and the like.  YMMV.


> I think we talked about this maybe off list.  On my old machine, when
> sddm comes up, the password field on the second monitor shows the dots,
> TV in my case.  On the new machine, both monitors show the dots for the
> password.  I'm not sure what is different tho.  It did that even before
> I set the primary option.  I like it that way myself but makes me
> curious why my main rig is different.  It seems the new rig sends the
> same screen to both monitors.  Once logged into KDE, it splits into two
> monitors.  My main rig it seems is always two separate screens. 

As far as I know SDDM is using the file(s) in /usr/share/sddm/scripts/ to 
start a login GUI.  I haven't looked into how far can these be tweaked for a 
dual monitor setup and if they even have a 'primary' monitor concept.


> I got some things going on.  I'll read the email closer later and make
> some changes.  I'll post back then.  Oh, so far, it shows several
> packages headed in the right direction.  The monitor stand left a small
> hub and when it leaves there, it almost always gets delivered that day. 
> So, I may get the monitor stand today.  The new /home hard drive is on
> the right path too.  I'm expecting quite a lot of packages.  While
> proofing this, got text from USPS that stand and several other packages
> are out for delivery.  UPS updates a little later. 
> 
> Oh, in /etc/X11/xorg.conf.d/ when the files are numbered, does it read
> them from low to high?  

Yes.

> If I set a option in one file but set the same
> option differently in another file, which one does it apply?  Or does it
> not apply either? 

First the lower numbered file, then the higher numbered file (see man run-
parts).  Also see explanation in the URL below.

> Thanks for the info.  :-D  Will work on it shortly. 
> 
> Dale
> 
> :-)  :-) 

https://wiki.gentoo.org/wiki/Xorg.conf

The separate files in /etc/X11/xorg.conf.d/ are meant to break things up and 
make it easier to check, add, or take out sections.  Configuration files are 
read in numeric order and sequentially, i.e. 10-monitor.conf will be read and 
applied before 20-monitor.conf, or 30-something-else.conf.  Files will be read 
in alphabetic order if they are not prefixed by a number.

Note, as the above URL points out, if you have a /etc/X11/xorg.conf file it 
will take precedence over any files in /etc/X11/xorg.conf.d/ and these in turn 
will take precedence over the default files installed in /usr/share/X11/
xorg.conf.d/.


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


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-10 Thread Dale
Michael wrote:
> On Wednesday, 10 July 2024 06:00:41 BST Dale wrote:
>> New subthread.  Slightly new situation. 
> [snip ...]
>> On the old LG monitor, when I first plugged up the new monitor, it
>> wouldn't power up from standby.  It wouldn't even when I connected only
>> the new monitor.  The BIOS would beep that it can't find a display as
>> well.  I thought at first I had a broken monitor.  Getting power but
>> won't wake up.  I tried another cable, it worked.  So, the first cable,
>> same as I used on the LG monitor, didn't work at all with the new
>> monitor.  Might be that the cable has a problem not the LG monitor
>> itself.  I didn't think of that.  I've used that cable quite often
>> before.  I'm not sure how old that cable is but it may find a trash can. 
> It is best you swap cables around to make sure you are not getting bad or 
> inconsistent results just because of a faulty cable.  It goes without saying 
> you should select a cable specification which is capable of the required 
> bandwidth for your card and monitor and do not gimp this via some lower 
> throughput adaptor in-between.
>
>
>> On to the new monitor.  I'm trying to decide whether to use xrandr and
>> friends to set this up or xorg.conf.  Using both seems to cause a bit of
>> a clash and KDE isn't helping any.  I'd kinda like to go the xorg.conf
>> route.  I think, but not sure, that xorg.conf is read very early on.  It
>> seems, but not sure, that the xinit files are read later on.  I'm not
>> sure on all that.  It could be the other way around.  I'm also pretty
>> sure that if set up in xorg.conf, it would work if I logged into another
>> GUI; Gnome, Fluxbox or some other flavor.
> Yes, xorg.conf would determine your screen layout for any window manager you 
> launch, unless the window manager/DE has its own specific layout 
> configuration 
> overriding the default xorg.conf file settings (using libxrandr).
>
>
>> It could be that xrandr and friends would as well.
> No, the xrandr extension of the X11 protocol is meant to be used to 
> dynamically change your settings in real time, or query X to obtain current 
> settings.  If you're running xrandr from a script, then it will change the X 
> settings when it is run.
>
> I suggest you use one tool at a time to avoid conflicts and duplication.
>
>
>> Current situation config wise.  The first problem I noticed, the
>> monitors are nearly identical.  Even the serial numbers are only a few
>> digits off and that's the only difference I can see.  I did some
>> searching and was wanting to set a option in xorg.conf Monitor section
>> that identifies the monitors by not only model but also serial number. 
>> That way I could set one to right or left of the other, or above/below,
>> and it know specifically which monitor is which, even if plugged into a
>> different port.  I can't find a option for serial number yet.  I did
>> find where someone else wanted to do the same a couple years ago but
>> sadly, no answer to that question.  So, if that is not doable, may have
>> to specify the port number.  If I ever have to disconnect and reconnect,
>> getting the order right could prove interesting.  ;-) 
> xrandr --listmonitors
>
> will show monitor number, which you can use as your monitor identifier in 
> xorg.conf, the port of the graphics card it is connected to, which you may 
> prefer to use as your monitor identifier in xorg.conf, if the monitor is 
> detected as the primary display or not, relevant screen position, size, and 
> other current settings of your display(s).
>
>
>> Right now, I have this:
>>
>>
>> root@Gentoo-1 ~ # cat /etc/X11/xinit/xinitrc.d/20.xrandr
>> xrandr --output DP-0 --off --output DP-1 --mode 1920x1080 --pos 1920x0
>> --rotate normal --output DP-2 --off --output DP-3 --primary --mode
>> 1920x1080 --pos 0x0 --rotate normal --output DP-4 --off --output DP-5
>> --off --output DP-6 --off --output DP-7 --off
>> root@Gentoo-1 ~ #
>>
>>
>> From what I've read, that is the correct place for that command.  If
>> not, please let me know where it should be.  Keep in mind, putting it in
>> /usr somewhere gets overwritten when the package providing that file
>> gets updated.
> It is a correct place to put it, if you intend running xrandr to change your 
> monitor layout every time you launch X, from whatever it would otherwise be 
> detected as.
>
>
>> I'm also attaching the current xorg.conf file.  Keep in
>> mind, gotta add the TV later on.  I think if I can get the monitors set
>> up, I can add the TV pretty easily.  Even if it only works in KDE, that
>> is fine since I need KDE up and running to use the TV anyway.  I'm
>> mostly needing to know if there is a way to add the serial number for
>> xorg.conf.  I think the rest is OK.  I also need a command to get what
>> the system sees as the serial number, in case it only sees a part of it,
>> last few digits or something.
> I don't think specifying a serial number is necessary.  Use the 
> identification 
> xrandr 

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-10 Thread Michael
On Wednesday, 10 July 2024 06:00:41 BST Dale wrote:
> New subthread.  Slightly new situation. 
[snip ...]
> On the old LG monitor, when I first plugged up the new monitor, it
> wouldn't power up from standby.  It wouldn't even when I connected only
> the new monitor.  The BIOS would beep that it can't find a display as
> well.  I thought at first I had a broken monitor.  Getting power but
> won't wake up.  I tried another cable, it worked.  So, the first cable,
> same as I used on the LG monitor, didn't work at all with the new
> monitor.  Might be that the cable has a problem not the LG monitor
> itself.  I didn't think of that.  I've used that cable quite often
> before.  I'm not sure how old that cable is but it may find a trash can. 

It is best you swap cables around to make sure you are not getting bad or 
inconsistent results just because of a faulty cable.  It goes without saying 
you should select a cable specification which is capable of the required 
bandwidth for your card and monitor and do not gimp this via some lower 
throughput adaptor in-between.


> On to the new monitor.  I'm trying to decide whether to use xrandr and
> friends to set this up or xorg.conf.  Using both seems to cause a bit of
> a clash and KDE isn't helping any.  I'd kinda like to go the xorg.conf
> route.  I think, but not sure, that xorg.conf is read very early on.  It
> seems, but not sure, that the xinit files are read later on.  I'm not
> sure on all that.  It could be the other way around.  I'm also pretty
> sure that if set up in xorg.conf, it would work if I logged into another
> GUI; Gnome, Fluxbox or some other flavor.

Yes, xorg.conf would determine your screen layout for any window manager you 
launch, unless the window manager/DE has its own specific layout configuration 
overriding the default xorg.conf file settings (using libxrandr).


> It could be that xrandr and friends would as well.

No, the xrandr extension of the X11 protocol is meant to be used to 
dynamically change your settings in real time, or query X to obtain current 
settings.  If you're running xrandr from a script, then it will change the X 
settings when it is run.

I suggest you use one tool at a time to avoid conflicts and duplication.


> Current situation config wise.  The first problem I noticed, the
> monitors are nearly identical.  Even the serial numbers are only a few
> digits off and that's the only difference I can see.  I did some
> searching and was wanting to set a option in xorg.conf Monitor section
> that identifies the monitors by not only model but also serial number. 
> That way I could set one to right or left of the other, or above/below,
> and it know specifically which monitor is which, even if plugged into a
> different port.  I can't find a option for serial number yet.  I did
> find where someone else wanted to do the same a couple years ago but
> sadly, no answer to that question.  So, if that is not doable, may have
> to specify the port number.  If I ever have to disconnect and reconnect,
> getting the order right could prove interesting.  ;-) 

xrandr --listmonitors

will show monitor number, which you can use as your monitor identifier in 
xorg.conf, the port of the graphics card it is connected to, which you may 
prefer to use as your monitor identifier in xorg.conf, if the monitor is 
detected as the primary display or not, relevant screen position, size, and 
other current settings of your display(s).


> Right now, I have this:
> 
> 
> root@Gentoo-1 ~ # cat /etc/X11/xinit/xinitrc.d/20.xrandr
> xrandr --output DP-0 --off --output DP-1 --mode 1920x1080 --pos 1920x0
> --rotate normal --output DP-2 --off --output DP-3 --primary --mode
> 1920x1080 --pos 0x0 --rotate normal --output DP-4 --off --output DP-5
> --off --output DP-6 --off --output DP-7 --off
> root@Gentoo-1 ~ #
> 
> 
> From what I've read, that is the correct place for that command.  If
> not, please let me know where it should be.  Keep in mind, putting it in
> /usr somewhere gets overwritten when the package providing that file
> gets updated.

It is a correct place to put it, if you intend running xrandr to change your 
monitor layout every time you launch X, from whatever it would otherwise be 
detected as.


> I'm also attaching the current xorg.conf file.  Keep in
> mind, gotta add the TV later on.  I think if I can get the monitors set
> up, I can add the TV pretty easily.  Even if it only works in KDE, that
> is fine since I need KDE up and running to use the TV anyway.  I'm
> mostly needing to know if there is a way to add the serial number for
> xorg.conf.  I think the rest is OK.  I also need a command to get what
> the system sees as the serial number, in case it only sees a part of it,
> last few digits or something.

I don't think specifying a serial number is necessary.  Use the identification 
xrandr provides for each monitor.


> I also had to argue with KDE about which is primary.  At first, like
> with the LG, it wanted to make 

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-09 Thread Dale
New subthread.  Slightly new situation. 

New monitor came in today.  It seems the truck from Memphis got delayed
and didn't arrive in time for yesterday.  No idea why it took over 14 or
15 hours to travel what would take no more than 2 or 3 hours even by
truck.  Maybe the truck broke down.  Oh, monitor stand is stuck in the
USPS State hub still, like most packages do.  I have another unrelated
package that was sent to the wrong post office.  Can those folks not get
it together  Anyway.

On the old LG monitor, when I first plugged up the new monitor, it
wouldn't power up from standby.  It wouldn't even when I connected only
the new monitor.  The BIOS would beep that it can't find a display as
well.  I thought at first I had a broken monitor.  Getting power but
won't wake up.  I tried another cable, it worked.  So, the first cable,
same as I used on the LG monitor, didn't work at all with the new
monitor.  Might be that the cable has a problem not the LG monitor
itself.  I didn't think of that.  I've used that cable quite often
before.  I'm not sure how old that cable is but it may find a trash can. 

On to the new monitor.  I'm trying to decide whether to use xrandr and
friends to set this up or xorg.conf.  Using both seems to cause a bit of
a clash and KDE isn't helping any.  I'd kinda like to go the xorg.conf
route.  I think, but not sure, that xorg.conf is read very early on.  It
seems, but not sure, that the xinit files are read later on.  I'm not
sure on all that.  It could be the other way around.  I'm also pretty
sure that if set up in xorg.conf, it would work if I logged into another
GUI; Gnome, Fluxbox or some other flavor.  It could be that xrandr and
friends would as well. 

Current situation config wise.  The first problem I noticed, the
monitors are nearly identical.  Even the serial numbers are only a few
digits off and that's the only difference I can see.  I did some
searching and was wanting to set a option in xorg.conf Monitor section
that identifies the monitors by not only model but also serial number. 
That way I could set one to right or left of the other, or above/below,
and it know specifically which monitor is which, even if plugged into a
different port.  I can't find a option for serial number yet.  I did
find where someone else wanted to do the same a couple years ago but
sadly, no answer to that question.  So, if that is not doable, may have
to specify the port number.  If I ever have to disconnect and reconnect,
getting the order right could prove interesting.  ;-) 

Right now, I have this:


root@Gentoo-1 ~ # cat /etc/X11/xinit/xinitrc.d/20.xrandr
xrandr --output DP-0 --off --output DP-1 --mode 1920x1080 --pos 1920x0
--rotate normal --output DP-2 --off --output DP-3 --primary --mode
1920x1080 --pos 0x0 --rotate normal --output DP-4 --off --output DP-5
--off --output DP-6 --off --output DP-7 --off
root@Gentoo-1 ~ #


>From what I've read, that is the correct place for that command.  If
not, please let me know where it should be.  Keep in mind, putting it in
/usr somewhere gets overwritten when the package providing that file
gets updated.  I'm also attaching the current xorg.conf file.  Keep in
mind, gotta add the TV later on.  I think if I can get the monitors set
up, I can add the TV pretty easily.  Even if it only works in KDE, that
is fine since I need KDE up and running to use the TV anyway.  I'm
mostly needing to know if there is a way to add the serial number for
xorg.conf.  I think the rest is OK.  I also need a command to get what
the system sees as the serial number, in case it only sees a part of it,
last few digits or something.

I also had to argue with KDE about which is primary.  At first, like
with the LG, it wanted to make the second monitor the primary despite
the first monitor being marked primary.  I did the old set it backwards,
apply and then set it back the way I want it trick.  It took it a second
but KDE reversed it.  Main screen went to the primary display.  This is
what I mean by it clashing and me setting the displays up in xorg.conf
and KDE hopefully getting its info from that and adjusting itself. 
Plus, if I use a different GUI, it should work too. 

Oh, new hard drive for /home should be here tomorrow.  It's coming UPS
so they pretty good on delivery times.  They beat USPS every day of the
week.  Anyway, USPS claims the new delivery date for monitor stand is
tomorrow too.  When I see it in my mailbox, I'll believe it.  ;-) 

I plan to do some rebooting to see if things come up consistently as
is.  It has booted once the way it should.  Still, I'd like to set up
xorg.conf to make sure things work well despite any changes hardware
wise, like monitors plugged into different ports.  I think, could be
wrong, that is the best way long term.  I could use xrandr which is
likely the second best option. 

These new monitors sure are nice.  My old eyes like them.  o_O  Oh, I
was going to copy over the KDE config directories.  I think I'm going to
take 

Re: [gentoo-user] Emails are no indexable

2024-07-09 Thread Vitaly Zdanevich

In https://marc.info/robots.txt I see

User-agent: *
Disallow: /

It looks bad.

On 7/8/24 21:41, Michael wrote:

On Monday, 8 July 2024 16:07:59 BST Vitaly Zdanevich wrote:

Hi, I tried to google in "exact match" a few sentences from this email
list - and nothing found. For example this mirroring
https://marc.info/?l=gentoo-user=171984189706185=2  - and nothing in
Google. Is it excluded from search? This is bad, because people google
problems that are already solved in these emails :(

Is it a known issue?

It depends what Google or other web crawlers have decided to list in their
search results and what to exclude.  You should be able to run a search within
the content of a single website, but only if it has been ranked/listed by
Google, e.g. say you want to find posts about blurred fonts, in a gentoo M/L,
but not Debian, contained in marc.info.  You can search Google like so:

"blurred fonts" +gentoo -debian site:marc.info

This should include Gentoo M/L posts about blurred fonts found in the
marc.info domain, but exclude any Debian related search results.
Unfortunately, this relies on Google first ranking them in their results to
allow you to see them.

[gentoo-user] Re: Fonts: was: New monitor, new problem. Everything LARGE O_O

2024-07-09 Thread Nuno Silva
On 2024-07-07, Jack wrote:

> To how fonts are designed, many if not most modern fonts (such as  
> true-type) are specified internally by the commands to draw each  
> character, and you request the size in points.  The conversion to how  
> many pixels to use is based on the DPI the system thinks is being used  
> by the monitor.  Some fonts are actually specified by the Width x  
> Height in pixels.  These are bitmap fonts, which often come in sets of  
> various sizes.  Fortunately (as far as I can tell) there are fewer and  
> fewer bitmap fonts in use any more, as they need to get very larger for  
> higher DPI displays.  You can imagine that mixing the two is even more  
> likely to lead to confusion and poor looking display, unless you are  
> extremely careful.

That's funny, because in my experience the fonts that render poorly are
the non-bitmap ones, and often the best way to get a clear, crisp,
readable text display here is by using bitmap fonts.

Now I'd like to know why are non-bitmap ones so often rendering
poorly. While I've tried to explore settings in the past, I don't think
I've discovered a satisfactory set of settings for non-bitmap. Maybe
some day in the future I'll revisit this...

-- 
Nuno Silva




Re: [gentoo-user] Updating profile

2024-07-09 Thread Dale
Thelma wrote:
> On 7/8/24 17:07, Dale wrote:
>> Thelma wrote:
>>> I'm on profile:
>>> default/linux/amd64/17.1/desktop (exp) *
>>>
>>> but it seems to me it is obsolete.  Has anybody switched to a new
>>> profile?
>>> How complicated is it?
>>>
>>> Gentoo instruction page is not very clear.
>>> ==>  NEW default/linux/amd64/23.0/split-usr
>>>               (added "split-usr")
>>>
>>> My eselect profile list shows:
>>> default/linux/amd64/23.0/desktop (stable)
>>> Do I need to "split-user" to the end?
>>>
>>> default/linux/amd64/23.0/desktop/split-usr  ??
>>>
>>> The 17.1 profile will apparently be removed after one year.
>>> Does it mean my system will not be able to upgrader after profile 17.1
>>> is removed?
>>>
>>
>>
>> Pretty sure this is the news item for profile switch to 23.
>>
>> https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions
>>
>> If you can post what profile you are currently on, I'm sure one of us
>> can point out the one you need to switch to.  The naming is slightly
>> different.  It is important to follow the instructions pretty well.
>> Example, before switching, you need to complete your emerge upgrade.
>> Usually emerge -auDN world will get you there..  Then do the profile
>> switch.  I tried skipping that step and it didn't go well.  Luckily I
>> was in a chroot and could just start over.
>>
>> Dale
>>
>> :-)  :-)
>>
> I'm on profile:
> default/linux/amd64/17.1/desktop (exp) *
>
> But it seems to me, it might be easier and quicker to just reinstall
> Gentoo
>
>
>

I just did a new install on a new puter.  It doesn't take that long.  I
might add, you need to upgrade first then do a emerge -e world after you
switch and rebuild some of the toolchain.  So, you will be compiling
some packages twice.  If you are already familiar with the install, you
can likely reinstall pretty fast.  I'd save files in /etc and the world
file. 

A added bonus, it is also a good time to start with a stage3 that has
the merged /usr as well.  Just make sure you have /usr on / itself.  At
least, that is how I did it.  At some point, odds are, you will have to
merge it anyway.  Reinstalling and switching to that as well will just
get you further ahead. 

I'd certainly consider it if it is a machine you can have down during
the install and all and have time to get a fresh start.  Just make sure
you save important stuff if you just dd a drive and start fresh. 

Dale

:-)  :-) 



Re: [gentoo-user] Updating profile

2024-07-09 Thread Wols Lists

On 09/07/2024 06:25, Arve Barsnes wrote:

On Tue, 9 Jul 2024 at 00:41, Thelma  wrote:


I'm on profile:
default/linux/amd64/17.1/desktop (exp) *

but it seems to me it is obsolete.  Has anybody switched to a new profile?
How complicated is it?

Gentoo instruction page is not very clear.
==>  NEW default/linux/amd64/23.0/split-usr
   (added "split-usr")

My eselect profile list shows:
default/linux/amd64/23.0/desktop (stable)
Do I need to "split-user" to the end?

default/linux/amd64/23.0/desktop/split-usr  ??

The 17.1 profile will apparently be removed after one year.
Does it mean my system will not be able to upgrader after profile 17.1 is 
removed?


You have understood perfectly which profile to switch to, the new
profile equivalent to your old one is the 'split-usr' one. If you
follow the instructions in the news item it is not very complicated at
all. If you have any problems, touch back here for help.

Note that following the instructions is important. I had a few problems 
along the way, but in part it was down to me missing items, and in 
others my system was set up in a manner that didn't quite behave in the 
normal manner.


IFF you've set it, make sure you disable EMERGE_DEFAULT_OPTS for the 
upgrade.


Cheers,
Wol




Re: [gentoo-user] Updating profile

2024-07-08 Thread Arve Barsnes
On Tue, 9 Jul 2024 at 00:41, Thelma  wrote:
>
> I'm on profile:
> default/linux/amd64/17.1/desktop (exp) *
>
> but it seems to me it is obsolete.  Has anybody switched to a new profile?
> How complicated is it?
>
> Gentoo instruction page is not very clear.
> ==>  NEW default/linux/amd64/23.0/split-usr
>   (added "split-usr")
>
> My eselect profile list shows:
> default/linux/amd64/23.0/desktop (stable)
> Do I need to "split-user" to the end?
>
> default/linux/amd64/23.0/desktop/split-usr  ??
>
> The 17.1 profile will apparently be removed after one year.
> Does it mean my system will not be able to upgrader after profile 17.1 is 
> removed?

You have understood perfectly which profile to switch to, the new
profile equivalent to your old one is the 'split-usr' one. If you
follow the instructions in the news item it is not very complicated at
all. If you have any problems, touch back here for help.

Cheers,
Arve



Re: [gentoo-user] Updating profile

2024-07-08 Thread Thelma

On 7/8/24 17:07, Dale wrote:

Thelma wrote:

I'm on profile:
default/linux/amd64/17.1/desktop (exp) *

but it seems to me it is obsolete.  Has anybody switched to a new
profile?
How complicated is it?

Gentoo instruction page is not very clear.
==>  NEW default/linux/amd64/23.0/split-usr
              (added "split-usr")

My eselect profile list shows:
default/linux/amd64/23.0/desktop (stable)
Do I need to "split-user" to the end?

default/linux/amd64/23.0/desktop/split-usr  ??

The 17.1 profile will apparently be removed after one year.
Does it mean my system will not be able to upgrader after profile 17.1
is removed?




Pretty sure this is the news item for profile switch to 23.

https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions

If you can post what profile you are currently on, I'm sure one of us
can point out the one you need to switch to.  The naming is slightly
different.  It is important to follow the instructions pretty well.
Example, before switching, you need to complete your emerge upgrade.
Usually emerge -auDN world will get you there..  Then do the profile
switch.  I tried skipping that step and it didn't go well.  Luckily I
was in a chroot and could just start over.

Dale

:-)  :-)


I'm on profile:
default/linux/amd64/17.1/desktop (exp) *

But it seems to me, it might be easier and quicker to just reinstall Gentoo




Re: [gentoo-user] Updating profile

2024-07-08 Thread Dale
Thelma wrote:
> I'm on profile:
> default/linux/amd64/17.1/desktop (exp) *
>
> but it seems to me it is obsolete.  Has anybody switched to a new
> profile?
> How complicated is it?
>
> Gentoo instruction page is not very clear.
> ==>  NEW default/linux/amd64/23.0/split-usr
>              (added "split-usr")
>
> My eselect profile list shows:
> default/linux/amd64/23.0/desktop (stable)
> Do I need to "split-user" to the end?
>
> default/linux/amd64/23.0/desktop/split-usr  ??
>
> The 17.1 profile will apparently be removed after one year.
> Does it mean my system will not be able to upgrader after profile 17.1
> is removed?
>


Pretty sure this is the news item for profile switch to 23. 

https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions

If you can post what profile you are currently on, I'm sure one of us
can point out the one you need to switch to.  The naming is slightly
different.  It is important to follow the instructions pretty well. 
Example, before switching, you need to complete your emerge upgrade. 
Usually emerge -auDN world will get you there..  Then do the profile
switch.  I tried skipping that step and it didn't go well.  Luckily I
was in a chroot and could just start over. 

Dale

:-)  :-) 



Re: [gentoo-user] postfix error: External senders are prohibited to send to local recipient

2024-07-08 Thread Thelma

Thank you for the input.
Yes, you are correct, in my case "postfix" was missing "sasl" flag.
I needed to run:
postmap hash:/etc/postfix/saslpass

and add entry to:
/etc/postfix/sender_canonical

now it works; until Rogers decided to add something new.


On 7/7/24 23:24, da...@vnecke.de wrote:

Hello Thelma,

depends on how these files are configured in your main.cf.
If it says

smtp_sasl_password_maps = hash:/etc/postfix/saslpass
and/or
sender_canonical_maps = hash:/etc/postfix/sender_canonical

you have to build the hashtables with
postmap hash:/etc/postfix/saslpass
and/or
postmap hash:/etc/postfix/sender_canonical

A "postfix reload" (or a restart of the service) might be necessary after 
creating the hashtables.

Other filetypes might be supported too, have a look into "man postmap" for more 
info.

Kind regards,
David

Am 2024-07-07 07:12, schrieb Thelma:
...



... status=bounced (host mail.domain.com[69.xx.xxx.xxx] said: 550 5.7.1 
... External senders are prohibited to send to local 
recipients without authentication (in reply to RCPT TO command))

Does these two files need special command to activate them? They seem to be 
simple text files.

/etc/postfix/sender_canonical
/etc/postfix/saslpass


...





[gentoo-user] Updating profile

2024-07-08 Thread Thelma

I'm on profile:
default/linux/amd64/17.1/desktop (exp) *

but it seems to me it is obsolete.  Has anybody switched to a new profile?
How complicated is it?

Gentoo instruction page is not very clear.
==>  NEW default/linux/amd64/23.0/split-usr
             (added "split-usr")

My eselect profile list shows:
default/linux/amd64/23.0/desktop (stable)
Do I need to "split-user" to the end?

default/linux/amd64/23.0/desktop/split-usr  ??

The 17.1 profile will apparently be removed after one year.
Does it mean my system will not be able to upgrader after profile 17.1 is 
removed?

--
Thelma



Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-08 Thread Frank Steinmetzger
Am Mon, Jul 08, 2024 at 06:26:26PM +0100 schrieb Michael:

> Back to the previous topic, I have not yet found a case where changing the 
> scale by means of the desktop settings, arrives at non-blurred fonts.  The 
> clearest sharpest fonts are always rendered at the native monitor resolution, 
> at a 100% scale setting.  Am I missing a trick, or is this to be expected?

That doesn’t really make sense. Fonts are always rendered natively, no 
matter what size. Except if they are really rendered at 100 % and then the 
rendered bitmap is scaled by the GPU or somesuch.

Or because their hinting information is limited to a certain size range. 
This info gives the renderer special knowledge on how to render the glyphs.

Do you have screenshots?

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

One doesn’t eat salad, one feeds salat to one’s food.


signature.asc
Description: PGP signature


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-08 Thread Mark Knecht
On Mon, Jul 8, 2024 at 5:27 AM Dale  wrote:

> I don't know about cell phones but if using the youtube app, I'd think
> it would know what you are using and the resolution too.  To me, it
> looks like it would be best for everyone to only download what is needed
> and no more.  It saves bandwidth of the server, bandwidth for the user
> as well.

YouTube knows this and does this if you use the 'Auto' setting. For my
Kubuntu machine using Chrome as a browser I get 1080p. For my phone
using the YouTube app I get 480p by default.

If I choose an 8K video on my TV and watch network traffic I use a lot
more bandwidth than choosing the same 8K video on my phone.

Just my experience with YouTube, NetFlix and Prime. Mostly I
stream video from my library in Plex so I'm not bound by any
bandwidth limits with XFinity, but I suspect most for-pay services do
something similar.

- Mark


Re: [gentoo-user] Emails are no indexable

2024-07-08 Thread Michael
On Monday, 8 July 2024 16:07:59 BST Vitaly Zdanevich wrote:
> Hi, I tried to google in "exact match" a few sentences from this email
> list - and nothing found. For example this mirroring
> https://marc.info/?l=gentoo-user=171984189706185=2 - and nothing in
> Google. Is it excluded from search? This is bad, because people google
> problems that are already solved in these emails :(
> 
> Is it a known issue?

It depends what Google or other web crawlers have decided to list in their 
search results and what to exclude.  You should be able to run a search within 
the content of a single website, but only if it has been ranked/listed by 
Google, e.g. say you want to find posts about blurred fonts, in a gentoo M/L, 
but not Debian, contained in marc.info.  You can search Google like so:

"blurred fonts" +gentoo -debian site:marc.info

This should include Gentoo M/L posts about blurred fonts found in the 
marc.info domain, but exclude any Debian related search results.  
Unfortunately, this relies on Google first ranking them in their results to 
allow you to see them.


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


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-08 Thread Michael
On Monday, 8 July 2024 15:52:03 BST Peter Humphrey wrote:
> On Monday 8 July 2024 13:59:27 BST Wol wrote:
> > On 08/07/2024 13:27, Dale wrote:
> > > I don't know about cell phones but if using the youtube app, I'd think
> > > it would know what you are using and the resolution too.
> > 
> > BBC iPlayer,  ITVx. Along with the other Freeview apps for Channels 4 and
> > 5.> 
> > > To me, it
> > > looks like it would be best for everyone to only download what is needed
> > > and no more.
> > 
> > You'd think. Trouble is - most people DON'T think!
> > 
> > > It saves bandwidth of the server, bandwidth for the user
> > > as well.  Most people have unlimited nowadays but still, one would think
> > > a company like youtube would see the benefit of only sending enough
> > > resolution to get the job done.  If they do that for millions of users,
> > > it would have to save them some amount of money.  I'd think anyway.
> > 
> > Youtube doesn't (yet) have a monopoly on streaming, fortunately ...

;-)

> I don't know about dedicated services with their own clients, but anything
> you get via a web browser is tailored to your screen. That was so when I
> was operating a web site, anyway.

Still is the case today.  I have not worked on mobile apps, beyond their 
browsers, but the reasonable assumption must be mobile devices should only 
download what they are able to render.  It is really odd they don't do this - 
as Wol attests to.

Back to the previous topic, I have not yet found a case where changing the 
scale by means of the desktop settings, arrives at non-blurred fonts.  The 
clearest sharpest fonts are always rendered at the native monitor resolution, 
at a 100% scale setting.  Am I missing a trick, or is this to be expected?


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


[gentoo-user] Emails are no indexable

2024-07-08 Thread Vitaly Zdanevich
Hi, I tried to google in "exact match" a few sentences from this email 
list - and nothing found. For example this mirroring 
https://marc.info/?l=gentoo-user=171984189706185=2 - and nothing in 
Google. Is it excluded from search? This is bad, because people google 
problems that are already solved in these emails :(


Is it a known issue?


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-08 Thread Peter Humphrey
On Monday 8 July 2024 10:56:44 BST Michael wrote:

> The rule of thumb is to come as close as possible to the TV screen until you
> start seeing different pixels.  Then you back off a little bit and plonk
> your armchair there.

Correction: That's A rule of thumb. It's not what's recommended by TV 
salesmen. I like your version though.

-- 
Regards,
Peter.






Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-08 Thread Peter Humphrey
On Monday 8 July 2024 13:59:27 BST Wol wrote:
> On 08/07/2024 13:27, Dale wrote:
> > I don't know about cell phones but if using the youtube app, I'd think
> > it would know what you are using and the resolution too.
> 
> BBC iPlayer,  ITVx. Along with the other Freeview apps for Channels 4 and 5.
> > To me, it
> > looks like it would be best for everyone to only download what is needed
> > and no more.
> 
> You'd think. Trouble is - most people DON'T think!
> 
> > It saves bandwidth of the server, bandwidth for the user
> > as well.  Most people have unlimited nowadays but still, one would think
> > a company like youtube would see the benefit of only sending enough
> > resolution to get the job done.  If they do that for millions of users,
> > it would have to save them some amount of money.  I'd think anyway.
> 
> Youtube doesn't (yet) have a monopoly on streaming, fortunately ...

I don't know about dedicated services with their own clients, but anything you 
get via a web browser is tailored to your screen. That was so when I was 
operating a web site, anyway.

A script blocker in your browser may be able to thwart this query-reply about 
screen sizes; I don't know.

-- 
Regards,
Peter.






Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-08 Thread Wol

On 08/07/2024 13:27, Dale wrote:

I don't know about cell phones but if using the youtube app, I'd think
it would know what you are using and the resolution too. 


BBC iPlayer,  ITVx. Along with the other Freeview apps for Channels 4 and 5.


To me, it
looks like it would be best for everyone to only download what is needed
and no more. 


You'd think. Trouble is - most people DON'T think!


It saves bandwidth of the server, bandwidth for the user
as well.  Most people have unlimited nowadays but still, one would think
a company like youtube would see the benefit of only sending enough
resolution to get the job done.  If they do that for millions of users,
it would have to save them some amount of money.  I'd think anyway.


Youtube doesn't (yet) have a monopoly on streaming, fortunately ...

Cheers,
Wol



Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-08 Thread Dale
Michael wrote:
> On Monday, 8 July 2024 00:57:40 BST Dale wrote:
>> Frank Steinmetzger wrote:
>>> Am Sun, Jul 07, 2024 at 05:10:18PM -0500 schrieb Dale:
 It's hi res and a good deal.  :-D 
>>> Please define hi res. Full HD at 32″ is definitely not hi res. ;-P
>>> It’s about as much as CRTs back in the day, close to 1024×768 at 17″.
>> Well, I still consider 1080P hi res.  That's what I get for any monitor
>> or TV I buy.  The biggest thing I have is a 32" tho.  My rooms are
>> kinda
>> small.  No need for a 60" TV/monitor. 
> Well my TV sits over 4 m (that’s 13 feet for the imperialists) away from
> the sofa. So I splurged and got myself a 65″ one.
 Well, I saw on a website once where it gave info on distance, monitor
 size and what you are watching can factor in too.  It claimed that a 32"
 is the ideal size for my room.  Given my old eyes tho, a 42" might serve
 me better.  Thing is, I'm bad to watch old videos from the 80's, 70's
 and even 60's.  Most of those are 480P or if lucky, just a little higher
 resolution.  With those, monitor size can make videos worse.
>>> This websites’s goal probably was about covering your eyes’ natural field
>>> of view. Sitting at my desk, my 27 inch monitor appears only slight
>>> smaller than my 65 inch TV 4 m away. Watching 50s TV shows will be the
>>> same experience on both in those situations.
>>>
>>> If you want to fill that entire field of view with details, then
>>> naturally,
>>> a 50s TV show in 480p won’t suffice. The more of your viewing arc you want
>>> to cover, the more picture resolution you need. You basically want to map
>>> X amount of pixels on each degree of viewing arc. Physical units are
>>> great.
>>>
>>> It also goes into the other direction: people these days™ watch 4K movies
>>> on their phones. Why, just why? Even if the screen can display it
>>> physically, their eyes cannot resolve that fine detail, because the
>>> pixels are too small.
>>>
>>> -- Grüße | Greetings | Salut | Qapla’ Please do not share anything
>>> from, with or about me on any social network. How do you recognise a
>>> male hedgehog? It has one more spine.
>> Yea.  The website at the time was mostly likely to help people not buy a
>> TV that is wy to large. 
>>
>> I made a DVD of the TV series Combat for my neighbor.  That was when he
>> had a little smaller TV.  It said it looked like large blocks on the
>> screen.  He watched it tho.  lol  He sits about 10 feet from the TV.  It
>> is a nice TV tho.  All that smart stuff. 
>>
>> I agree, a device should pick a resolution that it can easily display
>> without downloading more than it needs.  There's really not much need
>> putting a 4K or even a 1080P video on a small cell phone.  Unless a
>> person is using a magnifying glass, they won't see the difference.  I
>> remember some of my old CRTs that ran at 720P.  For their small size,
>> that was plenty. 
> Devices send a viewport size to the server to fetch scaled images and fonts 
> as 
> required, instead of downloading a huge resolution only for it to be consumed 
> on the small screen of a phone or tablet.  I'm not sure how the screen size 
> information is shared between server-phone-TV when you mirror your phone on a 
> TV.

I was watching a video once on youtube.  I don't remember how but
somehow I found out what info is sent to youtube about what I'm watching
with.  It sent that I was using Linux, version of Firefox, and other
info but also included the resolution of my monitor.  Generally when I
watch a video on youtube, the highest it goes is 1080P.  After all, that
is the max I can display anyway.  It usually gives options for lower
resolution too.  I've read that a person can limit the amount of info
that is being sent.  In a way, I don't like it sharing much info but on
the other hand, it does make it easier for them to provide what I need. 

I don't know about cell phones but if using the youtube app, I'd think
it would know what you are using and the resolution too.  To me, it
looks like it would be best for everyone to only download what is needed
and no more.  It saves bandwidth of the server, bandwidth for the user
as well.  Most people have unlimited nowadays but still, one would think
a company like youtube would see the benefit of only sending enough
resolution to get the job done.  If they do that for millions of users,
it would have to save them some amount of money.  I'd think anyway. 

It looks like my monitor stand won't be here today.  It left New Jersey
but has not even made it to Memphis yet.  It goes from Memphis to the
State hub and then to my local post office.  It might be here tomorrow. 
If the State hub is slow like it usually is, could be Wednesday.  The
new monitor left Memphis last night.  I see no reason it won't be here
today, around lunch I'd think.  It is Monday so could be a little
later.  It's coming through FedEx tho. 

I also ordered a new hard drive.  I'm going 

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-08 Thread Wols Lists

On 08/07/2024 11:48, Michael wrote:

Devices send a viewport size to the server to fetch scaled images and fonts as
required, instead of downloading a huge resolution only for it to be consumed
on the small screen of a phone or tablet.  I'm not sure how the screen size
information is shared between server-phone-TV when you mirror your phone on a
TV.


You wish. Given that the broadcast organisations control both the 
sending server and the consuming app, and that fibre and 5g and 
youngsters with unlimited bandwidth give the impression that "bandwidth 
doesn't matter", monitoring my data usage tells me that these apps 
expect to stream and receive in whatever bandwidth is available, namely 
the single hi-res version on the broadcaster's servers.


Why should I pay £50/month for unlimited data, when my normal monthly 
usage hardly hits 500MB? I'm currently paying £6/m (the cheapest tariff 
available is £5) for unlimited phone, text, and 15GB with rollover. For 
10 months of the year that's effectively unlimited! Why should I pay so 
much more just because some idiot insists on spamming my paid-for 
bandwidth for stuff I can't even use !!!


Cheers,
Wol



Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-08 Thread Wols Lists

On 08/07/2024 10:57, Michael wrote:

will show you what different resolutions the streaming server offers and you
can then select the one you need/prefer.  Of course this is conditional on yt-
dlp being capable of parsing the stream you want to download and on the
streaming server offering different resolutions.


And on you even having a clue what the hell the url is, seeing as it's 
all hidden behind/inside the tv streaming app ... I would guess it's 
streaming a .ts ...


Cheers,
Wol



Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-08 Thread Michael
On Monday, 8 July 2024 00:57:40 BST Dale wrote:
> Frank Steinmetzger wrote:
> > Am Sun, Jul 07, 2024 at 05:10:18PM -0500 schrieb Dale:
> >> It's hi res and a good deal.  :-D 
> > 
> > Please define hi res. Full HD at 32″ is definitely not hi res. ;-P
> > It’s about as much as CRTs back in the day, close to 1024×768 at 17″.
>  
>  Well, I still consider 1080P hi res.  That's what I get for any monitor
>  or TV I buy.  The biggest thing I have is a 32" tho.  My rooms are
>  kinda
>  small.  No need for a 60" TV/monitor. 
> >>> 
> >>> Well my TV sits over 4 m (that’s 13 feet for the imperialists) away from
> >>> the sofa. So I splurged and got myself a 65″ one.
> >> 
> >> Well, I saw on a website once where it gave info on distance, monitor
> >> size and what you are watching can factor in too.  It claimed that a 32"
> >> is the ideal size for my room.  Given my old eyes tho, a 42" might serve
> >> me better.  Thing is, I'm bad to watch old videos from the 80's, 70's
> >> and even 60's.  Most of those are 480P or if lucky, just a little higher
> >> resolution.  With those, monitor size can make videos worse.
> > 
> > This websites’s goal probably was about covering your eyes’ natural field
> > of view. Sitting at my desk, my 27 inch monitor appears only slight
> > smaller than my 65 inch TV 4 m away. Watching 50s TV shows will be the
> > same experience on both in those situations.
> > 
> > If you want to fill that entire field of view with details, then
> > naturally,
> > a 50s TV show in 480p won’t suffice. The more of your viewing arc you want
> > to cover, the more picture resolution you need. You basically want to map
> > X amount of pixels on each degree of viewing arc. Physical units are
> > great.
> > 
> > It also goes into the other direction: people these days™ watch 4K movies
> > on their phones. Why, just why? Even if the screen can display it
> > physically, their eyes cannot resolve that fine detail, because the
> > pixels are too small.
> > 
> > -- Grüße | Greetings | Salut | Qapla’ Please do not share anything
> > from, with or about me on any social network. How do you recognise a
> > male hedgehog? It has one more spine.
> 
> Yea.  The website at the time was mostly likely to help people not buy a
> TV that is wy to large. 
> 
> I made a DVD of the TV series Combat for my neighbor.  That was when he
> had a little smaller TV.  It said it looked like large blocks on the
> screen.  He watched it tho.  lol  He sits about 10 feet from the TV.  It
> is a nice TV tho.  All that smart stuff. 
> 
> I agree, a device should pick a resolution that it can easily display
> without downloading more than it needs.  There's really not much need
> putting a 4K or even a 1080P video on a small cell phone.  Unless a
> person is using a magnifying glass, they won't see the difference.  I
> remember some of my old CRTs that ran at 720P.  For their small size,
> that was plenty. 

Devices send a viewport size to the server to fetch scaled images and fonts as 
required, instead of downloading a huge resolution only for it to be consumed 
on the small screen of a phone or tablet.  I'm not sure how the screen size 
information is shared between server-phone-TV when you mirror your phone on a 
TV.


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


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-08 Thread Michael
On Monday, 8 July 2024 00:14:59 BST Wol wrote:
> On 07/07/2024 23:29, Frank Steinmetzger wrote:
> > It also goes into the other direction: people these days™ watch 4K movies
> > on their phones. Why, just why? Even if the screen can display it
> > physically, their eyes cannot resolve that fine detail, because the
> > pixels are too small.
> What's worse, as far as I can tell, I have no control over the download
> resolution! Why would I want to download a video in Full HD, when I only
> have an HD Ready screen, and it's over a metered connection! So
> basically, I'm paying for resolution I can't see!
> 
> Cheers,
> Wol

yt-dlp -F 

will show you what different resolutions the streaming server offers and you 
can then select the one you need/prefer.  Of course this is conditional on yt-
dlp being capable of parsing the stream you want to download and on the 
streaming server offering different resolutions.



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


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-08 Thread Michael
On Sunday, 7 July 2024 23:29:21 BST Frank Steinmetzger wrote:
> Am Sun, Jul 07, 2024 at 05:10:18PM -0500 schrieb Dale:
> >  It's hi res and a good deal.  :-D 
> > >>> 
> > >>> Please define hi res. Full HD at 32″ is definitely not hi res. ;-P
> > >>> It’s about as much as CRTs back in the day, close to 1024×768 at 17″.
> > >> 
> > >> Well, I still consider 1080P hi res.  That's what I get for any monitor
> > >> or TV I buy.  The biggest thing I have is a 32" tho.  My rooms are
> > >> kinda
> > >> small.  No need for a 60" TV/monitor. 
> > > 
> > > Well my TV sits over 4 m (that’s 13 feet for the imperialists) away from
> > > the sofa. So I splurged and got myself a 65″ one.
> > 
> > Well, I saw on a website once where it gave info on distance, monitor
> > size and what you are watching can factor in too.  It claimed that a 32"
> > is the ideal size for my room.  Given my old eyes tho, a 42" might serve
> > me better.  Thing is, I'm bad to watch old videos from the 80's, 70's
> > and even 60's.  Most of those are 480P or if lucky, just a little higher
> > resolution.  With those, monitor size can make videos worse.
> 
> This websites’s goal probably was about covering your eyes’ natural field of
> view. Sitting at my desk, my 27 inch monitor appears only slight smaller
> than my 65 inch TV 4 m away. Watching 50s TV shows will be the same
> experience on both in those situations.
> 
> If you want to fill that entire field of view with details, then naturally,
> a 50s TV show in 480p won’t suffice. The more of your viewing arc you want
> to cover, the more picture resolution you need. You basically want to map
> X amount of pixels on each degree of viewing arc. Physical units are great.
> 
> It also goes into the other direction: people these days™ watch 4K movies on
> their phones. Why, just why? Even if the screen can display it physically,
> their eyes cannot resolve that fine detail, because the pixels are too
> small.

The rule of thumb is to come as close as possible to the TV screen until you 
start seeing different pixels.  Then you back off a little bit and plonk your 
armchair there.  Obviously with a UHD TV the higher pixel density at a given 
screen size means you can seat much closer - or buy a larger TV.  At some 
point the TV size becomes too large to provide a sharp non-pixelated image, if 
the room is small.  When I asked a friend why he kept upgrading his TV to ever 
larger sizes for what was becoming an obviously worse visual experience, he 
responded "... for a man there's no such thing as too large a TV size!".  o_O

The problem arises when you are watching old TV material recorded at a much 
lower resolution than UHD.  For these you have to move your seat further back 
when using a UHD TV, until the displayed pixels in the picture appear to merge 
and give a smooth(er) non-pixelated image.  The TV chipset will try upscaling/
interpolating and smoothing algos to improve the situation, but this won't 
fare well when the jump is from a VHS equivalent of 320 pixels to the 2160 of 
UHD.


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


Re: [gentoo-user] postfix error: External senders are prohibited to send to local recipient

2024-07-07 Thread david

Hello Thelma,

depends on how these files are configured in your main.cf.
If it says

smtp_sasl_password_maps = hash:/etc/postfix/saslpass
and/or
sender_canonical_maps = hash:/etc/postfix/sender_canonical

you have to build the hashtables with
postmap hash:/etc/postfix/saslpass
and/or
postmap hash:/etc/postfix/sender_canonical

A "postfix reload" (or a restart of the service) might be necessary 
after creating the hashtables.


Other filetypes might be supported too, have a look into "man postmap" 
for more info.


Kind regards,
David

Am 2024-07-07 07:12, schrieb Thelma:
...



... status=bounced (host mail.domain.com[69.xx.xxx.xxx] said: 550 5.7.1 
... External senders are prohibited to send to local 
recipients without authentication (in reply to RCPT TO command))


Does these two files need special command to activate them? They seem 
to be simple text files.


/etc/postfix/sender_canonical
/etc/postfix/saslpass


...



Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-07 Thread Dale
Frank Steinmetzger wrote:
> Am Sun, Jul 07, 2024 at 05:10:18PM -0500 schrieb Dale:
>
>> It's hi res and a good deal.  :-D 
> Please define hi res. Full HD at 32″ is definitely not hi res. ;-P
> It’s about as much as CRTs back in the day, close to 1024×768 at 17″.
 Well, I still consider 1080P hi res.  That's what I get for any monitor
 or TV I buy.  The biggest thing I have is a 32" tho.  My rooms are kinda
 small.  No need for a 60" TV/monitor. 
>>> Well my TV sits over 4 m (that’s 13 feet for the imperialists) away from 
>>> the 
>>> sofa. So I splurged and got myself a 65″ one.
>> Well, I saw on a website once where it gave info on distance, monitor
>> size and what you are watching can factor in too.  It claimed that a 32"
>> is the ideal size for my room.  Given my old eyes tho, a 42" might serve
>> me better.  Thing is, I'm bad to watch old videos from the 80's, 70's
>> and even 60's.  Most of those are 480P or if lucky, just a little higher
>> resolution.  With those, monitor size can make videos worse.
> This websites’s goal probably was about covering your eyes’ natural field of 
> view. Sitting at my desk, my 27 inch monitor appears only slight smaller 
> than my 65 inch TV 4 m away. Watching 50s TV shows will be the same 
> experience on both in those situations.
>
> If you want to fill that entire field of view with details, then naturally, 
> a 50s TV show in 480p won’t suffice. The more of your viewing arc you want 
> to cover, the more picture resolution you need. You basically want to map
> X amount of pixels on each degree of viewing arc. Physical units are great.
>
> It also goes into the other direction: people these days™ watch 4K movies on 
> their phones. Why, just why? Even if the screen can display it physically, 
> their eyes cannot resolve that fine detail, because the pixels are too small.
>
> -- Grüße | Greetings | Salut | Qapla’ Please do not share anything
> from, with or about me on any social network. How do you recognise a
> male hedgehog? It has one more spine.

Yea.  The website at the time was mostly likely to help people not buy a
TV that is wy to large. 

I made a DVD of the TV series Combat for my neighbor.  That was when he
had a little smaller TV.  It said it looked like large blocks on the
screen.  He watched it tho.  lol  He sits about 10 feet from the TV.  It
is a nice TV tho.  All that smart stuff. 

I agree, a device should pick a resolution that it can easily display
without downloading more than it needs.  There's really not much need
putting a 4K or even a 1080P video on a small cell phone.  Unless a
person is using a magnifying glass, they won't see the difference.  I
remember some of my old CRTs that ran at 720P.  For their small size,
that was plenty. 

Monitor stand hasn't made it to the State hub yet.  Doubtful it will
arrive tomorrow. 

Dale

:-)  :-) 


Re: Food was: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-07 Thread Dale
Jack wrote:
> On 2024.07.07 18:53, Dale wrote:
>> Going to cook a box of mac n cheese for supper.  I haven't had that in a
>> while.  ;-)  I wonder, what would it taste like with some basil in it. 
>> ROFL 
> Would be great if you made pesto out of the basil.
>
>


I mostly add basil to tomato and basil hamburger helper and tomato soup
with crackers.  There's also a basil pasta sauce I eat sometimes. 
Usually, I have to go sparingly with it since I never had a large amount
of it.  Now that I got a lot of it and really like basil, I'm open to
more options.  I might add, one of my planters is about ready for
picking again.  The other two may have another picking in them.  I've
picked a lot off them already.  They trying to go to seed.  I keep
pinching them off. 

Mac n cheese was good.  Got my meds taken for the day too. 

I'm still booting the new rig and shutting down a lot.  So far, the
screen has been normal every time.  It seems to be working really well. 
I'm looking forward to the new monitor coming in so I have something
dependable to work with.  I think once I get those two set up, setting
up the TV will be fairly easy.  I hope anyway.  I really like having
hair.  LOL 

Dale

:-)  :-) 



Food was: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-07 Thread Jack

On 2024.07.07 18:53, Dale wrote:
Going to cook a box of mac n cheese for supper.  I haven't had that  
in a
while.  ;-)  I wonder, what would it taste like with some basil in  
it. 

ROFL 

Would be great if you made pesto out of the basil.



Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-07 Thread Wol

On 07/07/2024 23:29, Frank Steinmetzger wrote:

It also goes into the other direction: people these days™ watch 4K movies on
their phones. Why, just why? Even if the screen can display it physically,
their eyes cannot resolve that fine detail, because the pixels are too small.


What's worse, as far as I can tell, I have no control over the download 
resolution! Why would I want to download a video in Full HD, when I only 
have an HD Ready screen, and it's over a metered connection! So 
basically, I'm paying for resolution I can't see!


Cheers,
Wol



Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-07 Thread Dale
Frank Steinmetzger wrote:
> Am Sun, Jul 07, 2024 at 02:06:04PM -0700 schrieb Mark Knecht:
>> On Sun, Jul 7, 2024 at 1:09 PM Frank Steinmetzger  wrote:
>>> Am Sat, Jul 06, 2024 at 07:32:49PM -0500 schrieb Dale:
>> 
>>> Well don’t mix up frame rate and scaling. 75 Hz vs. 60 is quite subtle,
>> you
>>> might not even notice 90 Hz. But changing DPI from 80 to 70 will mean an
>>> increase in fonts by 14 %.
>> So I understand the 14% calculation, but help me understand the underlying
>> technology. Is the DPI how a font file, which I presume is some fixed size,
>> like 25x25, gets scaled onto the screen? I'm not clear about the conversion
>> from the font to the number of dots used to draw the font on the screen.
> Yeah. So, big convoluted topic. ^^
>
> First, there is the physical pixel raster of the screen, which determines 
> the PPI value. But what may confuse people without knowing (I was very 
> confused in my early computing days when I was using Windows): font sizes 
> and their units. People usually think in pixels, but font sizes are given in 
> point, especially on modern Linux desktops. Historically, Points come from 
> lead typesetting, where 1 pt = 1/72 inch. And monitors of early publishing 
> machines (and I think at the time in general) all had 72 ppi, so if you have 
> a font size of 12 pt == 1/6 in == 4,233 mm on your screen, it will be 
> exactly the same size on the printed paper. No scaling necessary.
>
> I forgot some of the minutiae over time; AFAIR Windows 9x+ assumed a standard 
> density of 96 ppi and font sizes were set up in pixels in the control panel. 
> The monitor market was very homogeneous, there was not much diversity, so no 
> need for scaling factors. The default in Windows 2000 and XP was Tahoma at 8 
> pixel. And it was the same on Pocket PCs (PDAs with 3″ touch screens of 
> 240×320). So if you took a screenshot on all of those screens, the font was 
> identical to the pixel.
>
> No comes the clash between the logical and the physical world. Today we have
> - high-density screens like tablets and laptops: 4K at 14″ equals 315 ppi
> - the standard cheap office screen of 1900×1200 at 24″ equals 94 ppi
> - my 8 years old Thinkpad with FullHD at 12.5″ and 176 ppi
>
> A text of size 12 pixel will always be 12 pixels high, so it will appear 
> smaller to the eye when the pixels are small, and bigger when the pixels are 
> big.
>
> OTOH, a text at 12 pt should be displayed physically (in millimeters or 
> inches on the screen) at the same size no matter how fine a screen resolves 
> an image. So the computer needs to know how many pixels it needs to reach 
> that size. That’s where the ppi come in:
>
>font size in pt
> Number of pixels = --- * Screens density in pixel/in
>  1/96 pt/in
>
> The first factor gives you the font’s physical dimension in inch, the second 
> factor converts that into pixel height. The units all cancel each other out 
> with pixels remaining.
>
> That’s why you can enter the screen’s ppi into the settings (or use it 
> automatically, if possible). So the font size you set will be the same to 
> your eye no matter what monitor you plug in. The scaling factor business 
> hides that: 100 % means 96 ppi, 200 % means 192 ppi.
>
> This produces two “Unfortunately”s:
>
> Unfortunately 1: people don’t know what the scaling means and how it works 
> physically.
>
> Unfortunately 2: UI developers stick to this scaling factor idea. Everything 
> outside certain values (meaning integer multiples of 96) looks ugly. But 
> none of my screens have a ppi of n * 96. They are all inbetween (117, 176, 
> 216) and when I set the correct scaling, the Plasma UI becomes ugly as hell 
> because the previously nice-looking pixel-perfect lines become blurred or 
> their thickness varies depending on where on the screen they are drawn.
>

You and Jack shared some interesting info. 


>>> I’m confused. I thought the new one has already arrived and is the one
>> where everything was HUGE. %-)
>>
>> Dale does this at times and I get confused also. He will (the way I read the
>> messages) sometimes be talking about different machines or different
>> monitors. His 'main rig", his "new rig", etc.
> We could stick to hostnames. *ducksandruns*
>
> -- Grüße | Greetings | Salut | Qapla’ Please do not share anything
> from, with or about me on any social network. It’s a pity that at the
> end of the money there’s so much month left.

That's true.  Main rig is Fireball, new rig is Gentoo-1 for the moment. 
Then I have NAS 1 and NAS 2.  Those aren't exactly named that but it's
what I use when posting about them.  I couldn't come up with a new name
for the new rig that would be a increase in speed.  My first rig, long
retired, was named smoker.  Fireball was faster.  Thought about
lightening for new rig but kinda long. 

I do see some interesting names people use for their rigs on here tho. 
Some are quite neat.  I just couldn't think of 

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-07 Thread Frank Steinmetzger
Am Sun, Jul 07, 2024 at 05:10:18PM -0500 schrieb Dale:

>  It's hi res and a good deal.  :-D 
> >>> Please define hi res. Full HD at 32″ is definitely not hi res. ;-P
> >>> It’s about as much as CRTs back in the day, close to 1024×768 at 17″.
> >> Well, I still consider 1080P hi res.  That's what I get for any monitor
> >> or TV I buy.  The biggest thing I have is a 32" tho.  My rooms are kinda
> >> small.  No need for a 60" TV/monitor. 
> > Well my TV sits over 4 m (that’s 13 feet for the imperialists) away from 
> > the 
> > sofa. So I splurged and got myself a 65″ one.
> 
> Well, I saw on a website once where it gave info on distance, monitor
> size and what you are watching can factor in too.  It claimed that a 32"
> is the ideal size for my room.  Given my old eyes tho, a 42" might serve
> me better.  Thing is, I'm bad to watch old videos from the 80's, 70's
> and even 60's.  Most of those are 480P or if lucky, just a little higher
> resolution.  With those, monitor size can make videos worse.

This websites’s goal probably was about covering your eyes’ natural field of 
view. Sitting at my desk, my 27 inch monitor appears only slight smaller 
than my 65 inch TV 4 m away. Watching 50s TV shows will be the same 
experience on both in those situations.

If you want to fill that entire field of view with details, then naturally, 
a 50s TV show in 480p won’t suffice. The more of your viewing arc you want 
to cover, the more picture resolution you need. You basically want to map
X amount of pixels on each degree of viewing arc. Physical units are great.

It also goes into the other direction: people these days™ watch 4K movies on 
their phones. Why, just why? Even if the screen can display it physically, 
their eyes cannot resolve that fine detail, because the pixels are too small.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

How do you recognise a male hedgehog?
It has one more spine.


signature.asc
Description: PGP signature


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-07 Thread Frank Steinmetzger
Am Sun, Jul 07, 2024 at 02:06:04PM -0700 schrieb Mark Knecht:
> On Sun, Jul 7, 2024 at 1:09 PM Frank Steinmetzger  wrote:
> >
> > Am Sat, Jul 06, 2024 at 07:32:49PM -0500 schrieb Dale:
> 
> >
> > Well don’t mix up frame rate and scaling. 75 Hz vs. 60 is quite subtle,
> you
> > might not even notice 90 Hz. But changing DPI from 80 to 70 will mean an
> > increase in fonts by 14 %.
> 
> So I understand the 14% calculation, but help me understand the underlying
> technology. Is the DPI how a font file, which I presume is some fixed size,
> like 25x25, gets scaled onto the screen? I'm not clear about the conversion
> from the font to the number of dots used to draw the font on the screen.

Yeah. So, big convoluted topic. ^^

First, there is the physical pixel raster of the screen, which determines 
the PPI value. But what may confuse people without knowing (I was very 
confused in my early computing days when I was using Windows): font sizes 
and their units. People usually think in pixels, but font sizes are given in 
point, especially on modern Linux desktops. Historically, Points come from 
lead typesetting, where 1 pt = 1/72 inch. And monitors of early publishing 
machines (and I think at the time in general) all had 72 ppi, so if you have 
a font size of 12 pt == 1/6 in == 4,233 mm on your screen, it will be 
exactly the same size on the printed paper. No scaling necessary.

I forgot some of the minutiae over time; AFAIR Windows 9x+ assumed a standard 
density of 96 ppi and font sizes were set up in pixels in the control panel. 
The monitor market was very homogeneous, there was not much diversity, so no 
need for scaling factors. The default in Windows 2000 and XP was Tahoma at 8 
pixel. And it was the same on Pocket PCs (PDAs with 3″ touch screens of 
240×320). So if you took a screenshot on all of those screens, the font was 
identical to the pixel.

No comes the clash between the logical and the physical world. Today we have
- high-density screens like tablets and laptops: 4K at 14″ equals 315 ppi
- the standard cheap office screen of 1900×1200 at 24″ equals 94 ppi
- my 8 years old Thinkpad with FullHD at 12.5″ and 176 ppi

A text of size 12 pixel will always be 12 pixels high, so it will appear 
smaller to the eye when the pixels are small, and bigger when the pixels are 
big.

OTOH, a text at 12 pt should be displayed physically (in millimeters or 
inches on the screen) at the same size no matter how fine a screen resolves 
an image. So the computer needs to know how many pixels it needs to reach 
that size. That’s where the ppi come in:

   font size in pt
Number of pixels = --- * Screens density in pixel/in
 1/96 pt/in

The first factor gives you the font’s physical dimension in inch, the second 
factor converts that into pixel height. The units all cancel each other out 
with pixels remaining.

That’s why you can enter the screen’s ppi into the settings (or use it 
automatically, if possible). So the font size you set will be the same to 
your eye no matter what monitor you plug in. The scaling factor business 
hides that: 100 % means 96 ppi, 200 % means 192 ppi.

This produces two “Unfortunately”s:

Unfortunately 1: people don’t know what the scaling means and how it works 
physically.

Unfortunately 2: UI developers stick to this scaling factor idea. Everything 
outside certain values (meaning integer multiples of 96) looks ugly. But 
none of my screens have a ppi of n * 96. They are all inbetween (117, 176, 
216) and when I set the correct scaling, the Plasma UI becomes ugly as hell 
because the previously nice-looking pixel-perfect lines become blurred or 
their thickness varies depending on where on the screen they are drawn.


> > I’m confused. I thought the new one has already arrived and is the one
> where everything was HUGE. %-)
> 
> Dale does this at times and I get confused also. He will (the way I read the
> messages) sometimes be talking about different machines or different
> monitors. His 'main rig", his "new rig", etc.

We could stick to hostnames. *ducksandruns*

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

It’s a pity that at the end of the money there’s so much month left.


signature.asc
Description: PGP signature


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-07 Thread Dale
Frank Steinmetzger wrote:
> Am Sun, Jul 07, 2024 at 04:12:11PM -0500 schrieb Dale:
>
 It's hi res and a good deal.  :-D 
>>> Please define hi res. Full HD at 32″ is definitely not hi res. ;-P
>>> It’s about as much as CRTs back in the day, close to 1024×768 at 17″.
>> Well, I still consider 1080P hi res.  That's what I get for any monitor
>> or TV I buy.  The biggest thing I have is a 32" tho.  My rooms are kinda
>> small.  No need for a 60" TV/monitor. 
> Well my TV sits over 4 m (that’s 13 feet for the imperialists) away from the 
> sofa. So I splurged and got myself a 65″ one.

Well, I saw on a website once where it gave info on distance, monitor
size and what you are watching can factor in too.  It claimed that a 32"
is the ideal size for my room.  Given my old eyes tho, a 42" might serve
me better.  Thing is, I'm bad to watch old videos from the 80's, 70's
and even 60's.  Most of those are 480P or if lucky, just a little higher
resolution.  With those, monitor size can make videos worse.

My neighbor has a massive TV.  I think it is at least a 60".  He's
talking about a even larger one. Anything he watches has to be very high
res, above 1080p for sure.  UHD and 4K come to mind.  I'd hate to know
he wanted to watch a old TV series like Combat that was made in the 50's
I think and is usually in 360P at best.  Could even be 240P. 


 Now to go eat supper.  I hope the monitor comes in soon.
>>> I’m confused. I thought the new one has already arrived and is the one 
>>> where 
>>> everything was HUGE. %-)
>> I ordered a second identical monitor.  I been wanting two monitors for a
>> while.  On occasion when I have hundreds of files to process manually, I
>> need a second monitor just to stick a file manager on and drag files
>> from one directory to another but being able to see both at the same
>> time.
> I’ve never grown accustomed to multi-monitor-setups. I’ve always used just 
> one (a habit from my long laptop days). Instead I multitask with virtual 
> desktops (as you do) and with teminal multiplexers.
>
> At 70 DPI, I recommend the terminus font, a bitmap font which is very 
> readable at small sizes and allows you to get lots of information on the 
> screen.

I prefer a single monitor 95% of the time.  I'm fine with the TV part
since I almost view it as a separate thing.  I've even thought of
building a Raspberry Pi and using that to drive my TV with from a NAS
box.  That 5% of the time tho, I wish I had two monitors.  I might add,
I'm up to 18 virtual desktops.  Yes, at times, I have something on
almost all of them.  With the new rig and it having more memory, I'll
likely have 13 of those in use at all times with one more as my parking
desktop.  I have gkrellm on it and that is where I park when I'm not
sitting in the chair.  I can see gkrellm and monitor what is going on,
updates etc.  I use two more when I'm getting pics off my camera or cell
phone.  When I'm doing config updates, that's another desktop.  It adds
up fast.  My biggest limiting factor right now, memory in my current
rig.  Firefox, Seamonkey and Qbittorrent use a lot of memory.

>>   A second monitor will help with this.  Plus, I have a spare as
>> well.  So, first monitor is here and fixed a lot of problems except it
>> added a new one, being HUGE.  Now that is fixed as well.  When I connect
>> the second monitor, I should be able to set it up the same way except
>> connected to a different port.
> Considering that you have a thread about GPU temps going, be warned: GPUs 
> tend to suck a lot more power when running in multi-head setups.

Right now, the video card is mostly sitting at its lowest power level. 
It's also running very cool.  I don't see the extra monitors making much
difference.  I'm not going to be putting a load on that card even if I
use all the ports.  I think it goes beyond 1080P but my displays don't. 
Just that is going to make the card have less load.  Plus, that is the
fastest card I've ever bought. 


>> The biggest thing I dread right now, cleaning off my desk.  -_o
> A clean desk is just a sign for a messy drawer.
>

Funny you say that.  I plan to put some stuff in a drawer.  I have DVD
boot media, for those old systems where USB isn't bootable.  I mostly
use the Ventoy USB stick nowadays so the DVD stuff can be stuck in a
drawer, which I already have a large drawer full of this sort of stuff. 
That's where a lot of this is going.  I wish I had larger rooms. Heck, I
could use a 20' x 30' computer room.  If I had the money to build one of
those, I could fill it up with puters too.  ROFL 

Still can't figure out supper.  Starting to get hungry tho. 

Dale

:-)  :-) 


Fonts: was: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-07 Thread Jack

On 2024.07.07 17:06, Mark Knecht wrote:
[snip...]
So I understand the 14% calculation, but help me understand the  
underlying
technology. Is the DPI how a font file, which I presume is some fixed  
size,
like 25x25, gets scaled onto the screen? I'm not clear about the  
conversion
from the font to the number of dots used to draw the font on the  
screen.
When a program requests the system to display a character on the  
screen, depending on the specific font and the available font-drawing  
libraries, it can specify the size either in dots or some physical  
measure - inches, or more likely points.  Points are an "ancient"  
measure from the times of using real, lead type, stored in wooden  
cases, thus upper [capital letters] and lower [everything else] case.   
There are 72 points to the inch.  10 point type is 10/72" tall, but  
with enough spacing between rows, you typically get 6 rows per inch.   
(Sorry for being pedantic - many years ago I did spend some time  
printing with hand set type.)


To how fonts are designed, many if not most modern fonts (such as  
true-type) are specified internally by the commands to draw each  
character, and you request the size in points.  The conversion to how  
many pixels to use is based on the DPI the system thinks is being used  
by the monitor.  Some fonts are actually specified by the Width x  
Height in pixels.  These are bitmap fonts, which often come in sets of  
various sizes.  Fortunately (as far as I can tell) there are fewer and  
fewer bitmap fonts in use any more, as they need to get very larger for  
higher DPI displays.  You can imagine that mixing the two is even more  
likely to lead to confusion and poor looking display, unless you are  
extremely careful.



With my limited understanding it seems very arbitrary.

Not so arbitrary, but easily confusing.


With respect to Dale's "huge" problem there's also a scale factor in  
KDE
that can be set by the user, or could be set wrong such that it will  
scale

up what's drawn on the screen. (Display and Monitor->Global Scale)
And I'm really not sure where this scaling is applied relative the the  
points to pixels calculation of font size.


Hope this helps more than confuses.

Jack



Re: [gentoo-user] Video card temp and fan sensors.

2024-07-07 Thread Dale
Mark Knecht wrote:
>
>
> On Sun, Jul 7, 2024 at 1:54 PM Dale  > wrote:
> >
> > Mark Knecht wrote:
> >
> >
> >
> > On Wed, Jun 19, 2024 at 12:30 PM Dale  > wrote:
> 
> > Well, I wouldn't mind finding the file that has the temps.  I have a
> little simple script that uses cat, grep etc to get temps and fan info.
> 
>
> nvidia-smi -q -d TEMPERATURE
>
> nvidia-smi -h
> nvidia-smi -q -h
>
> to learn more.
>
> - Mark


That gave some good info.  I wonder, does gkrellm use that same info? 
Maybe it knows to check the output of that command to get the GPU
temps.  The only thing missing, fan.  I may need to edit grep to list it
as well since it is looking for temps.  ;-) 

Thanks for the info.  That gives me something to deal with.  Once I get
grep to grab what I want, I can add the command to my script.  :-D  This
is a good start tho.

Dale

:-)  :-) 


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-07 Thread Frank Steinmetzger
Am Sun, Jul 07, 2024 at 04:12:11PM -0500 schrieb Dale:

> >> It's hi res and a good deal.  :-D 
> > Please define hi res. Full HD at 32″ is definitely not hi res. ;-P
> > It’s about as much as CRTs back in the day, close to 1024×768 at 17″.
> 
> Well, I still consider 1080P hi res.  That's what I get for any monitor
> or TV I buy.  The biggest thing I have is a 32" tho.  My rooms are kinda
> small.  No need for a 60" TV/monitor. 

Well my TV sits over 4 m (that’s 13 feet for the imperialists) away from the 
sofa. So I splurged and got myself a 65″ one.

> >> Now to go eat supper.  I hope the monitor comes in soon.
> > I’m confused. I thought the new one has already arrived and is the one 
> > where 
> > everything was HUGE. %-)
> 
> I ordered a second identical monitor.  I been wanting two monitors for a
> while.  On occasion when I have hundreds of files to process manually, I
> need a second monitor just to stick a file manager on and drag files
> from one directory to another but being able to see both at the same
> time.

I’ve never grown accustomed to multi-monitor-setups. I’ve always used just 
one (a habit from my long laptop days). Instead I multitask with virtual 
desktops (as you do) and with teminal multiplexers.

At 70 DPI, I recommend the terminus font, a bitmap font which is very 
readable at small sizes and allows you to get lots of information on the 
screen.

>   A second monitor will help with this.  Plus, I have a spare as
> well.  So, first monitor is here and fixed a lot of problems except it
> added a new one, being HUGE.  Now that is fixed as well.  When I connect
> the second monitor, I should be able to set it up the same way except
> connected to a different port.

Considering that you have a thread about GPU temps going, be warned: GPUs 
tend to suck a lot more power when running in multi-head setups.

> The biggest thing I dread right now, cleaning off my desk.  -_o

A clean desk is just a sign for a messy drawer.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

“A computer is like air conditioning:
it becomes useless when you open Windows.” – Linus Torvalds


signature.asc
Description: PGP signature


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-07 Thread Dale
Mark Knecht wrote:
>
>
> On Sun, Jul 7, 2024 at 1:09 PM Frank Steinmetzger  > wrote:
> >
> > Am Sat, Jul 06, 2024 at 07:32:49PM -0500 schrieb Dale:
> 
> >
> > Well don’t mix up frame rate and scaling. 75 Hz vs. 60 is quite
> subtle, you
> > might not even notice 90 Hz. But changing DPI from 80 to 70 will mean an
> > increase in fonts by 14 %.
>
> So I understand the 14% calculation, but help me understand
> the underlying 
> technology. Is the DPI how a font file, which I presume is some fixed
> size, 
> like 25x25, gets scaled onto the screen? I'm not clear about the
> conversion 
> from the font to the number of dots used to draw the font on the screen.
>
> With my limited understanding it seems very arbitrary.
>
> With respect to Dale's "huge" problem there's also a scale factor in KDE
> that can be set by the user, or could be set wrong such that it will
> scale up
> what's drawn on the screen. (Display and Monitor->Global Scale)
>
> >
> > I’m confused. I thought the new one has already arrived and is the
> one where
> > everything was HUGE. %-)
>
> Dale does this at times and I get confused also. He will (the way I
> read the
> messages) sometimes be talking about different machines or different
> monitors. His 'main rig", his "new rig", etc.
>
> - Mark
>


Yea, I try to state which rig I'm talking about when giving info.  It is
confusing for me to at times and if I'm confused, well, my messages will
be too.  After all, I have new rig, main rig, NAS-1 and NAS-2.  It's a
lot to keep up with even for me.

I looked everywhere in KDE and even found and disabled some scale and
zoom features but it didn't change the screen at all.  When it first
started tho, that is what it looked like.  It was like looking through
binoculars or something.  It also looked like I was seeing one part of a
four monitor screen.  It's also why I asked if setting the DPI  could
give a hint about another setting that could also fix the issue. I've
never had to set DPI before.  I find it very odd.  It fixes it but could
another more common option also fix it. 

It's almost supper time.  Nothing cooked and no idea what I want.  Two
deep freezers with food, lots of ammo cans with other food, stuff in
fridge and all, still can't make up my mind on what to eat.  :/   I got
plenty of basil to spice up things tho.  Dang I got a LOT of basil. 

We going to get this all sorted out tho and then the new rig will become
main rig.  That should lead to more confusion.  ROFL 

Dale

:-)  :-)


Re: [gentoo-user] Video card temp and fan sensors.

2024-07-07 Thread Mark Knecht
On Sun, Jul 7, 2024 at 1:54 PM Dale  wrote:
>
> Mark Knecht wrote:
>
>
>
> On Wed, Jun 19, 2024 at 12:30 PM Dale  wrote:

> Well, I wouldn't mind finding the file that has the temps.  I have a
little simple script that uses cat, grep etc to get temps and fan info.


nvidia-smi -q -d TEMPERATURE

nvidia-smi -h
nvidia-smi -q -h

to learn more.

- Mark


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-07 Thread Dale
Frank Steinmetzger wrote:
> Am Sat, Jul 06, 2024 at 07:32:49PM -0500 schrieb Dale:
>
>> Michael wrote:
>>> On Saturday, 6 July 2024 17:11:23 BST Dale wrote:
 Michael wrote:
> On Saturday, 6 July 2024 10:59:30 BST Dale wrote:
>> Now the monitor on my main rig is a bit older too.  Maybe 6 or 7
>> years???  Should newer monitors be set to a higher number for DPI?
> DPI does not depend on age, but only on physical characteristics, of course. 

Yea, but I figure monitors have improved and have more of them and
closer together.  Maybe they are as tight as they can get them, for now
at least.  Just wait, they will have them at several thousand a inch
before long.  ROFL  If nothing else, it makes a good sales pitch.  o_O

>
> Strictly speaking, the pixel density of an on-screen digital image is
> referred to as Pixels Per Inch (PPI), but the term DPI which refers to a
> printed image of ink Dots Per Inch has stuck.
>
> In addition, there is the physical pixel density of your monitor and the
> rendered pixel density of the X11 image(s).  Tweaking the latter allows
> you to scale the display and make images look larger than the native
> monitor resolution.
>>> Is this your monitor?
>>>
>>> https://www.samsung.com/us/business/computing/monitors/flat/32--s30b-fhd-75hz-amd-freesync-monitor-ls32b300nwnxgo/#specs
>>>
>>> If the screen is 27.5" wide and 15.47 high, then at a native 1,920 x 1,080 
>>> pixel resolution the DPI would be approx. 70x70.  However, if you're happy 
>>> with the way it looks @80x80, then that's a good setting.  After all, 
>>> you're 
>>> the one looking at it!  :-)
>> Actually, mine is a LS32B304NWN.  I'm not sure what the difference is
>> between 300 and 304.  There may just be a minor version change but
>> display is the same.
> If I look at the Samsung pages:
> https://www.samsung.com/us/computing/monitors/flat/32--s30b-fhd-75hz-amd-freesync-monitor-ls32b300nwnxgo/
> https://www.samsung.com/us/business/computing/monitors/flat/32--s30b-series-with-dp-cable-ls32b304nwnxgo/
> then the difference is in the caption: the 304 comes with a DP cable.
>

Well, I think it did come with one of those.  I stuck it somewhere.  My
video card has mini displayport outputs. I have a short adapter that
converts to HDMI.  That's how I connect right now.  I may buy a cable
that has MiniDP on one end and whatever works best for the monitor on
the other.  Less connectors.  For my use, I doubt it matters any.

>> It's hi res and a good deal.  :-D 
> Please define hi res. Full HD at 32″ is definitely not hi res. ;-P
> It’s about as much as CRTs back in the day, close to 1024×768 at 17″.

Well, I still consider 1080P hi res.  That's what I get for any monitor
or TV I buy.  The biggest thing I have is a 32" tho.  My rooms are kinda
small.  No need for a 60" TV/monitor. 

>> Compared to the HUGE display, yea, it looks good.  The reason I was
>> asking if that is correct is this, maybe it should be set to, just
>> guessing, 128 x 128 but some other setting makes the picture the right
>> size, not HUGE.  If 70 x 70 or 80 x 80 is a setting that the monitor is
>> designed for and ideal, then that is fine.
> Well technically, a monitor is not designed for, but designed with a 
> specific number. It is determined by the size of its physical pixels.
>
>> Monitors, even the old CRTs, have resolutions and settings they work
>> best at.
> True, at bigger pictures (meaning more pixels), the frame rate went down and 
> the CRT started to visibly flicker. So the sweet spot was at the highest 
> resolution for which a comfortably high framerate could be maintained. I was 
> too little in the CRT era to know the exact reason, but there are many to 
> choose from:
> - insufficient GPU power to deliver enough pixels per second
> - limited bandwidth in the display cable
> - the monitor couldn’t keep up
> - the CRT’s pixel pitch in the phosphor screen
>
>> I read once where a
>> person had a monitor that had a great picture at 60Hz refresh.  Even tho
>> it would work at 75Hz, the picture wasn't as good.  It seems that
>> something didn't like that 75Hz setting.  That person used the 60Hz
>> setting.  Some things are picky that way.  Higher isn't always better.
> How long ago was that? If it was in the VGA era, maybe the analog circuits 
> weren’t good enough and produced a bad signal.

Could also just be a difference in what the monitor could handle and
what the video card can produce.  I just remember reading that a guy had
to use a lower refresh rate because the faster setting looked worse. 
Could have been the eyes tho.  o_O


>> I may try that 70 setting.  Odds are, just like the difference between
>> 60 and 75Hz refresh rate, I likely won't be able to tell the
>> difference.  Time will tell tho. 
> Well don’t mix up frame rate and scaling. 75 Hz vs. 60 is quite sublte, you 
> might not even notice 90 Hz. But chaing DPI from 80 to 70 will mean an 
> increase in fonts by 14 %.
>

I set it 

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-07 Thread Mark Knecht
On Sun, Jul 7, 2024 at 1:09 PM Frank Steinmetzger  wrote:
>
> Am Sat, Jul 06, 2024 at 07:32:49PM -0500 schrieb Dale:

>
> Well don’t mix up frame rate and scaling. 75 Hz vs. 60 is quite subtle,
you
> might not even notice 90 Hz. But changing DPI from 80 to 70 will mean an
> increase in fonts by 14 %.

So I understand the 14% calculation, but help me understand the underlying
technology. Is the DPI how a font file, which I presume is some fixed size,
like 25x25, gets scaled onto the screen? I'm not clear about the conversion
from the font to the number of dots used to draw the font on the screen.

With my limited understanding it seems very arbitrary.

With respect to Dale's "huge" problem there's also a scale factor in KDE
that can be set by the user, or could be set wrong such that it will scale
up
what's drawn on the screen. (Display and Monitor->Global Scale)

>
> I’m confused. I thought the new one has already arrived and is the one
where
> everything was HUGE. %-)

Dale does this at times and I get confused also. He will (the way I read the
messages) sometimes be talking about different machines or different
monitors. His 'main rig", his "new rig", etc.

- Mark


Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

2024-07-07 Thread Wols Lists

On 07/07/2024 21:08, Frank Steinmetzger wrote:

I read once where a
person had a monitor that had a great picture at 60Hz refresh.  Even tho
it would work at 75Hz, the picture wasn't as good.  It seems that
something didn't like that 75Hz setting.  That person used the 60Hz
setting.  Some things are picky that way.  Higher isn't always better.



How long ago was that? If it was in the VGA era, maybe the analog circuits
weren’t good enough and produced a bad signal.


In Europe, I think many CRTs were 50Hz. Basically, you need at least 
24Hz to fool the eye that it's a moving picture. And if I'm correct (I 
never really dug into that), it's clearly something to do with the 
frequency of the AC supplying the monitor.


I know that has a whole series of weird effects that are "oh THAT'S why" 
when it's pointed out.


Cheers,
Wol



Re: [gentoo-user] Video card temp and fan sensors.

2024-07-07 Thread Dale
Mark Knecht wrote:
>
>
> On Wed, Jun 19, 2024 at 12:30 PM Dale  > wrote:
> >
> > Howdy,
> >
> > I got the new Nvidia Quadro P1000 video card in the other day.  I got it
> > installed.
> 
> >
> > Any ideas?  Thanks.
> >
> > Dale
> it's not much but nvidia-smi does show a list of GPUs and has one
> temperature reading per GPU on my system
>
> nvtop shows GPU usage and also shows 1 temperature reading.
>
> For me both temp readings match.
>
> Not sure how much that helps with you wanting one app that shows
> everything but at least it's a reading..
>
> - Mark


Well, I wouldn't mind finding the file that has the temps.  I have a
little simple script that uses cat, grep etc to get temps and fan info. 
I use it if I have to compile something while in console, in other
words, the GUI isn't working but I want to see if everything is running
at a good temp.  It's rare but I try to have that just in case.  Thing
is, when there is no GUI running, the GPU won't have much of a load on
it so it should run cool.  Still, I wouldn't mind knowing where that
files is, just to be able to see all the temps, fans and such even with
no GUI. 

On most every computer I've got, the info is under
/sys/devices/platform//hwmon/hwmon*/ and I can use cat
to grab the info.  I've looked everywhere and think it may be a AUXTIN*
but not sure exactly which one or even if it is one of those.  I may get
some software, stress-ng may be able to do this, and stress the GPU a
bit and see what temps rises.  Odds are, that is the right one, if it is
one of those.  At that point, I can dig in /sys and see if I can find a
file with the same value. 

I find it odd that it is so difficult to figure out which file is what
temp.  One would think mobo makers would have a page somewhere that
shares that info so anyone and everyone can know for sure what they
have.  After all, even Windows shows temp and fan info.  At this point
tho, at least gkrellm shows the info.  It's a start. 

By the way, I been booting and shutting down the new rig a LOT today.  I
added DM to the default run level. It has booted and had a normal screen
every single time.  Adding the DPI value to the xorg.conf file seems to
have fixed the large screen issue.  Micheal and I have been chatting off
list.  Neither of us remember having to set that even back in the old
CRT days.  No clue why it isn't being picked up by the GUI tools.  After
all, this is a very new monitor.  I may be getting last years model at
this price point but still, it should chat with the video card and Linux
very well. 

My second monitor left the Memphis hub.  It's on the way to the local
delivery place now.  It should be here tomorrow.  The monitor stand
shows it is on the way.  I doubt it will make it here tomorrow but it
claims it will.  I'm thinking Tuesday tho.  The State hub is not that
quick and it has not even arrived at the State hub yet.  It was in New
Jersey this morning I think.  That's a ways off for a ground package. 
Air could make it but I doubt ground will.  I hope they surprise me.  LOL 

Dale

:-)  :-) 


  1   2   3   4   5   6   7   8   9   10   >