Re: debian testing, kernel 5.6 et nvidia optimus

[Haricophile]

Le Tue, 5 May 2020 14:53:23 +0200,
Jérémy Prego  a écrit :

> bonjour,
> 
> Depuis ce matin, ma debian testing est passé au noyau 5.6. depuis ce
> passage, j'ai bbswitch-dkms qui ne veut plus se compiler. En
> conséquence, je viens vers vous pour savoir ce qui se fait de mieux
> aujourd'hui pour gérer la carte nvidia au mieu avec le pilote libre, si
> possible. mon pc est toujours le dell g5 15 5587.
> # lspci |grep -i nvidia
> 01:00.0 3D controller: NVIDIA Corporation GP107M [GeForce GTX 1050 Ti
> Mobile] (rev a1)
> 
> Il faut savoir qu'avec bumblebee / bbswitch, ça ne fonctionnait déjà pas
> bien, j'avais un souci lors du réveil de la carte, avec un message du
> genre: ":01:00.0: Refused to change power state, /currently in D3/".
> Par contre, même si j'avais ce message, je constatait que la carte se
> réveillait quand même, puisque le pc se mettait à chauffer ~10° en plus.
> La seule solution pour éteindre la carte
> était d'arrêter le pc complètement, avant de le rallumer bien sûr. un
> simple reboot ne suffisait pas.
> 
> J'avais commencé a faire des recherches sur ce sujet mais vu la
> complexité de ce que j'avais trouvé et que ça s'appliquait peut être pas
> a debian, j'ai pas poursuivi.
> 
> En conséquence, je viens vers vous, pour prendre des nouvelles à jour
> sur optimus avec debian, avec le pilote libre, de préférence :) ce que
> je trouve sur le net est souvent de 2012/2013 ...
> 
> merci d'avance de m'avoir lu et de vos réponses :)
> 
> Jerem

Alors comme je suis enschtroumphé pour mettre le double écran avec mon HP
avec un HDMI branchée sur NVIDIA, je me suis résout à mettre Ubuntu.

Je n'utilise pas Bumblebee mais l'outil de config de NVIDIA qui me propose
3 choix :

1. NVIDIA only que j'utilise branché sur secteur pour les ecrans
multiples;

2. INTEL only pour réduire la consommation de la batterie si je me déplace;

3. «a la demande» que je n'ai pas testé, c'est à dire le comportement
de Bumblebee;

A noter qu'il faut redémarrer le serveur X pour changer entre ces paramètre.

Je ne dis pas que ce soit parfait, mais ça fonctionne.



# aptitude search '~i ~d nvidia'

i A libnvidia-cfg1-440
- Bibliothèque de configuration OpenGL/GLX binaire NVIDIA

i A libnvidia-common-440
   -
Fichiers partagés utilisés par les bibliothèques NVIDIA



i A libnvidia-compute-440
   -
Paquet libcompute NVIDIA



i A libnvidia-compute-440:i386
   -
Paquet libcompute NVIDIA



i A libnvidia-decode-440
   -
Bibliothèques d'exécution de décodage vidéo NVIDIA



i A libnvidia-decode-440:i386
   -
Bibliothèques d'exécution de décodage vidéo NVIDIA



i A libnvidia-encode-440
   -
Bibliothèque d’exécution d'encodage vidéo NVENC



i A libnvidia-encode-440:i386
   -
Bibliothèque d’exécution d'encodage vidéo NVENC



i A libnvidia-extra-440
   -
Extra libraries for the NVIDIA driver



i A libnvidia-fbc1-440
   -
NVIDIA OpenGL-based Framebuffer Capture runtime library



i A libnvidia-fbc1-440:i386
   -
NVIDIA OpenGL-based Framebuffer Capture runtime library



i A libnvidia-gl-440
   -
Bibliothèques NVIDIA OpenGL/GLX/EGL/GLES GLVND et ICD Vulkan



i A libnvidia-gl-440:i386
   

Re: Looking for video card recommendation

[Anders Andersson]

On Wed, May 6, 2020 at 7:02 PM Alberto Sentieri <2...@tripolho.com> wrote:
>
> Thanks. Adding contrib solved the problem.
>
> On 5/5/20 8:24 PM, Alexander V. Makartsev wrote:
> > On 05.05.2020 20:29, Alberto Sentieri wrote:
> >> Last time I installed it I downloaded the driver from NVIDIA web
> >> site. I was able to install it and it worked well, but updates
> >> started bothering me. Maybe I should have tried a Debian repo, but I
> >> did not and I have no recollection of the reason.
> >>
> >> Anyway, I was trying to install it now using debian repos (deb
> >> http://deb.debian.org/debian/ buster main non-free), as you
> >> suggested, and I got this. Any suggestion?
> >>
> >> # nvidia-detect
> >> Detected NVIDIA GPUs:
> >> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119
> >> [NVS 310] [10de:107d] (rev a1)
> >>
> >> Checking card:  NVIDIA Corporation GF119 [NVS 310] (rev a1)
> >> Your card is only supported up to the 390 legacy drivers series.
> >> It is recommended to install the
> >> nvidia-legacy-390xx-driver
> >> package.
> >> # apt-get install nvidia-legacy-390xx-driver
> >> Reading package lists... Done
> >> Building dependency tree
> >> Reading state information... Done
> >> Some packages could not be installed. This may mean that you have
> >> requested an impossible situation or if you are using the unstable
> >> distribution that some required packages have not yet been created
> >> or been moved out of Incoming.
> >> The following information may help to resolve the situation:
> >>
> >> The following packages have unmet dependencies:
> >>  nvidia-legacy-390xx-driver : PreDepends: nvidia-installer-cleanup
> >> but it is not installable
> >>   Depends:
> >> nvidia-legacy-390xx-driver-libs (= 390.116-1) but it is not going to
> >> be installed or
> >> nvidia-legacy-390xx-driver-libs-nonglvnd (= 390.116-1) but it is not
> >> going to be installed
> >>   Depends: nvidia-legacy-390xx-driver-bin
> >> (= 390.116-1) but it is not going to be installed
> >>   Depends:
> >> xserver-xorg-video-nvidia-legacy-390xx (= 390.116-1) but it is not
> >> going to be installed
> >>   Depends:
> >> nvidia-legacy-390xx-vdpau-driver (= 390.116-1) but it is not going to
> >> be installed
> >>   Depends:
> >> nvidia-legacy-390xx-alternative (= 390.116-1) but it is not going to
> >> be installed
> >>   Depends:
> >> nvidia-legacy-390xx-kernel-dkms (= 390.116-1) but it is not going to
> >> be installed or
> >> nvidia-legacy-390xx-kernel-390.116
> >>   Depends: nvidia-support but it is not
> >> installable
> >>   Recommends:
> >> nvidia-settings-legacy-390xx but it is not installable
> >>   Recommends: libnvidia-legacy-390xx-cfg1
> >> (= 390.116-1) but it is not going to be installed
> >>   Recommends: nvidia-persistenced but it
> >> is not installable
> >> E: Unable to correct problems, you have held broken packages.
> >>
> >
> > Package "nvidia-installer-cleanup" is in "contrib" section, so you
> > have to add it too. Don't forget to invoke "apt update" after that.


Just a reminder for people who are going to search for this in the
future. We live in a world where you vote with your wallet. Try not to
support manufacturers who are working against you when you want to use
a free platform.

Re: Actualizar OpenGL

[Camaleón]

El 2020-05-06 a las 21:06 +0200, Imeneo Tirinto escribió:

> On Wed, May 6, 2020 at 8:16 PM Camaleón  wrote:
> 
> > El 2020-05-06 a las 19:39 +0200, Imeneo Tirinto escribió:

(...)

> > > [  1600.155] (II) LoadModule: "glx"
> > > [  1600.156] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
> > > [  1600.158] (II) Module glx: vendor="X.Org Foundation"
> >
> > > [  1600.160] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
> >
> > > [  1600.160] (II) modeset(0): using drv /dev/dri/card0
> >
> > > [  1600.188] (II) modeset(0): glamor X acceleration enabled on Mesa DRI
> > Intel(R) Ironlake Desktop
> > > [  1600.256] (II) modeset(0): [DRI2] Setup complete
> > > [  1600.256] (II) modeset(0): [DRI2]   DRI driver: i965
> > > [  1600.256] (II) modeset(0): [DRI2]   VDPAU driver: i965
> > > [  1600.262] (II) Initializing extension DRI3
> > > [  1600.262] (II) Initializing extension GLX
> > > [  1600.273] (II) AIGLX: Loaded and initialized i965
> > > [  1600.273] (II) GLX: Initialized DRI2 GL provider for screen 0
> > > [  1600.273] (II) Initializing extension XFree86-DRI
> > > [  1600.273] (II) Initializing extension DRI2
> >
> > Hasta aquí todo parece correcto.
> > Gráfica intel, KMS habilitado, carga la aceleración (GLX y DRI2/3) y
> > Glamour. La versión de MESA que tienes instala (18.3.6x) admite OpenGL
> > 3.x sin problemas¹.
> >
> > No dices qué error te da exactamente la aplicación que quieres ejecutar
> > pero si no te funciona o te pide una versión superior de OpenGL quizá
> > sea debido a que tu tarjeta ya no lo admite. Esta tabla² te puede
> > servir de guía.
> >
> > Si ejecutas «glxinfo | grep "version"» (paquete mesa-utils)  te dirá tu
> > versión actual de OpenGL, que atendiendo a la tabla anterior debería ser
> > la 2.1 o 2.0.
> >
> > ¹ https://www.mesa3d.org/faq.html
> > ² https://wiki.gentoo.org/wiki/Intel#Hardware_detection

> Tengo la versión 2.0.

Hum...
 
> El programa que quiero instalar es OBS Studio, que indica que necesito
> OpenGl 3.3
> https://obsproject.com/wiki/install-instructions#linux
> 
> No he probado a instalarlo.

Ah, está disponible en los repositorios de Debian:

https://packages.debian.org/buster/obs-studio

Y efectivamente, pide dos cosas:

1. Tarjeta gráfica que admita OpenGL 3.2
2. Controladores gráficos con soporte OpenGL 3.2

En tu caso, los drivers no son un problema, pero la gráfica sí, me temo
;-(

Pero no pierdes nada por probar. Si no quieres instalarlo en tu sistema, 
puedes cargar una versión Live(CD/USB) que se ejecuta desde el medio 
sin alterar la instalación actual en el disco duro e instalar la 
aplicación, a ver qué pasa. Me parecería excesivo que no se pudiera 
ejecutar siquiera; lo que quizá sí tenga sea funciones bloqueadas al no 
disponer del soporte para la versión OpenGL que necesita.

Saludos,

-- 
Camaleón 

Re: [HS?][testing] erreur de certificat orange

[Jacques]

Le 02/05/2020 à 09:48, Jacques a écrit :
> Bonjour,
> 
> Il s'agit bien d'un pb côté orange. Sur certains de leurs serveurs les
> certificats ssl ne sont pas corrects:
> 


Ce soir tous les serveurs pop et imap d'orange sont enfin mis à jour
avec des certificats SSL correctement installés.

Bonne soirée

Jacques

Re: Verkeerde tijd ondanks NTP

[Paul van der Vlis]

Op 06-05-2020 om 10:44 schreef Heiko Noordhof:
> Hoi,
> 
> Net als MJ zijn wij ook op chrony overgestapt en dat bevalt heel goed.
> Duidelijker configuratie en documentatie. (om te beginnen bruikbare man
> pages)

Ik heb nu ook chrony op een machine geinstalleerd. Lijkt zo in eerste
instantie prima.

Groeten,
Paul




-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Slow performance due to llvmpipe being used despite Radeon kernel and X modules being loaded

[EoflaOE ViceCity]

Hello. Sorry for the length of this problem, but I am trying to get the X
server to use my graphics card, AMD Radeon 9200 SE (RV280), instead of my
CPU to render things on the desktop. I actually have a newer computer, but
I use the older computer for experiments. Here's how the problem goes.

Last month, I have installed Debian 10 on my old computer for testing
purposes, and upgraded it to testing to test newer versions of packages to
see if there are bugs.

When I installed XScreenSaver to have fancy idling animations because MATE
Screensaver has only generic ones, I have noticed that the screensavers
were running slower than usual, even after increasing frame rate (-delay 0)
in screensavers.

I have looked up for clues, and found the command, glxinfo, to list details
about the OpenGL rendering. So, I executed the command, and found that it
is using llvmpipe instead of the Radeon driver (open source, not fglrx).

"glxinfo | grep OpenGL":

OpenGL vendor string: *VMware, Inc.*
OpenGL renderer string: *llvmpipe (LLVM 9.0.1, 128 bits)*
OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.3.3
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.1 Mesa 19.3.3
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 19.3.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:

To ensure that all of the necessary Radeon modules were loaded correctly, I
have grepped the X server logs (/var/log/Xorg.0.log) and dmesg with
"radeon" and "drm", as well as the "inxi -G" output, and found the
following information:

X server logs "cat /var/log/Xorg.0.log | grep -i radeon":

[55.616] (II) Applying OutputClass "Radeon" to /dev/dri/card0
[55.616]loading driver: radeon
[55.617] (==) Matched radeon as autoconfigured driver 0
[55.617] (II) LoadModule: "radeon"
[55.859] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
[56.161] (II) Module radeon: vendor="X.Org Foundation"
[56.951] (II) RADEON: Driver for ATI/AMD Radeon chipsets:
-truncated-
..., ATI Radeon 9200, ATI Radeon 9200SE, ...
-truncated-
[57.164] (II) RADEON(0): Creating default Display subsection in Screen
section
[57.164] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32
[57.165] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32
bpp pixmaps)
[57.165] (==) RADEON(0): Default visual is TrueColor
[57.165] (==) RADEON(0): RGB weight 888
[57.165] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
[57.165] (--) RADEON(0): Chipset: "ATI Radeon 9200SE" (ChipID = 0x5964)
[57.527] (II) RADEON(0): KMS Color Tiling: disabled
[57.527] (II) RADEON(0): KMS Color Tiling 2D: disabled
[57.527] (==) RADEON(0): TearFree property default: auto
[57.527] (II) RADEON(0): KMS Pageflipping: enabled
[57.527] (II) RADEON(0): SwapBuffers wait for vsync: enabled
[57.756] (II) RADEON(0): Output VGA-0 has no monitor section
[57.766] (II) RADEON(0): Output S-video has no monitor section
[57.828] (II) RADEON(0): EDID for output VGA-0
[57.831] (II) RADEON(0): Manufacturer: ACR  Model: 1a  Serial#:
2451600041
[57.831] (II) RADEON(0): Year: 2009  Week: 22
[57.831] (II) RADEON(0): EDID Version: 1.3
[57.831] (II) RADEON(0): Analog Display Input,  Input Voltage Level:
0.700/0.300 V
[57.831] (II) RADEON(0): Sync:  Separate
[57.831] (II) RADEON(0): Max Image Size [cm]: horiz.: 41  vert.: 26
[57.831] (II) RADEON(0): Gamma: 2.20
[57.831] (II) RADEON(0): DPMS capabilities: StandBy Suspend Off;
RGB/Color Display
[57.831] (II) RADEON(0): First detailed timing is preferred mode
[57.831] (II) RADEON(0): redX: 0.636 redY: 0.349   greenX: 0.290
greenY: 0.589
[57.831] (II) RADEON(0): blueX: 0.143 blueY: 0.080   whiteX: 0.313
whiteY: 0.329
[57.831] (II) RADEON(0): Supported established timings:
[57.831] (II) RADEON(0): 720x400@70Hz
[57.831] (II) RADEON(0): 640x480@60Hz
[57.831] (II) RADEON(0): 640x480@67Hz
[57.831] (II) RADEON(0): 640x480@72Hz
[57.831] (II) RADEON(0): 640x480@75Hz
[57.831] (II) RADEON(0): 800x600@56Hz
[57.831] (II) RADEON(0): 800x600@60Hz
[57.831] (II) RADEON(0): 800x600@72Hz
[57.831] (II) RADEON(0): 800x600@75Hz
[57.831] (II) RADEON(0): 832x624@75Hz
[57.831] (II) RADEON(0): 1024x768@60Hz
[57.832] (II) RADEON(0): 1024x768@70Hz
[57.832] (II) RADEON(0): 1024x768@75Hz
[57.832] (II) RADEON(0): 1280x1024@75Hz
[57.832] (II) RADEON(0): 1152x864@75Hz
[57.832] (II) RADEON(0): Manufacturer's mask: 10
[57.832] (II) RADEON(0): Supported standard timings:
[57.832] (II) RADEON(0): #0: hsize: 1440  vsize 900  refresh: 60  vid:
149
[57.832] (II) RADEON(0): #1: hsize: 1440  vsize 900  

Re: Actualizar OpenGL

[Imeneo Tirinto]

Tengo la versión 2.0.

El programa que quiero instalar es OBS Studio, que indica que necesito
OpenGl 3.3
https://obsproject.com/wiki/install-instructions#linux

No he probado a instalarlo.



On Wed, May 6, 2020 at 8:16 PM Camaleón  wrote:

> El 2020-05-06 a las 19:39 +0200, Imeneo Tirinto escribió:
>
> > On Wed, May 6, 2020 at 7:15 PM Camaleón  wrote:
> >
> > > El 2020-05-06 a las 18:01 +0200, Imeneo Tirinto escribió:
>
> (...)
>
> > > > > El 2020-05-06 a las 10:20 +0200, Imeneo Tirinto escribió:
> > > > >
> > > > > > Necesito actualizar a la versión 3.3 o superior de OpenGl para
> poder
> > > > > > utilizar un programa. Actualmente estoy en Debian Buster, y con
> > > OpenGL
> > > > > 2.2.
> > > > > > He buscado por Google pero no he encontrado la manera de
> actualizar
> > > a la
> > > > > > versión que necesito.
> > > > >
> > > > > Normalmente, la versión de GLX está vinculada (depende) del driver
> que
> > > > > tengas instalado para tu gráfica y de sus capacidades (tanto de
> > > > > hardware como de software).
> > > > >
> > > > > Si nos dices qué gráfica tienes y qué driver has instalado, mejor.
> > > > >
> > > > > ¿Qué te devuelve esta orden?
> > > > >
> > > > > sm01@stt008:~$ grep -i level /var/log/Xorg.0.log
> > > > > [16.687] (==) NOUVEAU(0): Allowed maximum DRI level 2.
> > > > > [16.863] (==) NOUVEAU(G0): Allowed maximum DRI level 2.
> > > > >
> > >
> > > > El log de Xorg no está en la ruta que indicas, la tengo en
> > > > /home/usuario/.local/share/Xorg y devuelve lo siguiente
> > > > *[  1600.219] (II) modeset(0): Analog Display Input,  Input Voltage
> > > Level:
> > > > 0.700/0.700 V*
> > >
> > > Hum... qué ruta más extraña >:-)
> > >
> > > Pues entonces prueba con:
> > >
> > > grep -i -e glx -e dri $HOME/.local/share/Xorg/*.0.log
>
> (...)
>
> > Lo que sale es lo siguiente
> >
> (...)
>
> > [  1600.155] (II) LoadModule: "glx"
> > [  1600.156] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
> > [  1600.158] (II) Module glx: vendor="X.Org Foundation"
>
> > [  1600.160] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
>
> > [  1600.160] (II) modeset(0): using drv /dev/dri/card0
>
> > [  1600.188] (II) modeset(0): glamor X acceleration enabled on Mesa DRI
> Intel(R) Ironlake Desktop
> > [  1600.256] (II) modeset(0): [DRI2] Setup complete
> > [  1600.256] (II) modeset(0): [DRI2]   DRI driver: i965
> > [  1600.256] (II) modeset(0): [DRI2]   VDPAU driver: i965
> > [  1600.262] (II) Initializing extension DRI3
> > [  1600.262] (II) Initializing extension GLX
> > [  1600.273] (II) AIGLX: Loaded and initialized i965
> > [  1600.273] (II) GLX: Initialized DRI2 GL provider for screen 0
> > [  1600.273] (II) Initializing extension XFree86-DRI
> > [  1600.273] (II) Initializing extension DRI2
>
> Hasta aquí todo parece correcto.
> Gráfica intel, KMS habilitado, carga la aceleración (GLX y DRI2/3) y
> Glamour. La versión de MESA que tienes instala (18.3.6x) admite OpenGL
> 3.x sin problemas¹.
>
> No dices qué error te da exactamente la aplicación que quieres ejecutar
> pero si no te funciona o te pide una versión superior de OpenGL quizá
> sea debido a que tu tarjeta ya no lo admite. Esta tabla² te puede
> servir de guía.
>
> Si ejecutas «glxinfo | grep "version"» (paquete mesa-utils)  te dirá tu
> versión actual de OpenGL, que atendiendo a la tabla anterior debería ser
> la 2.1 o 2.0.
>
> ¹ https://www.mesa3d.org/faq.html
> ² https://wiki.gentoo.org/wiki/Intel#Hardware_detection
>
> Saludos,
>
> --
> Camaleón
>
>

-- 
Imeneo
http://cousasdeimeneo.net/
http://twitter.com/cousasdeimeneo

Re: Debian testing ou stable ?

[ajh-valmer]

On Wednesday 06 May 2020 20:08:35 Haricophile wrote:
> Le Tue, 5 May 2020 19:44:10 +0200,
> Belaïd  a écrit :
> > Pour ce genre de question, j'imagine toujours  ce que donnerait un système
> > embarqué en cours de développement (Testing, unstable ...) installé dans
> > un avion de ligne !

> Eh bien grâce à Boing, nous savons ! :

Plutôt "Boeing-Boeing", pièce comique de boulevards,
dans les années soixantes avec Louis de Funès.

Re: debian testing, kernel 5.6 et nvidia optimus

[didier gaumet]

Le 06/05/2020 à 18:24, Jérémy Prego a écrit :
[...]
> ici, l'option prime est interressante, mais sous debian, ça ne semble
> fonctionner qu'avec les driver proprio ...

peut-être plus d'infos ici:
 https://nouveau.freedesktop.org/wiki/Optimus/

> après, est-ce que c'est normal que bbswitch ne se compile plus en 5.6,
> ça j'ai pas trouvé de réponse efficace sur le sujet ... 
[...]

la page sur le suivi de bugs Debian de bbswitch-dkms en unstable est là:
 https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=bbswitch-dkms;dist=unstable

l'impossibilité de construire le module avec le noyau 5.6 correspond au
bug #959189 (30/4/2020)

tes problèmes d'utilisation pourraient correspondre au bug  #941884
 (7/10/2019)

 comme je suis une grosse feignasse et que j'ai des besoins assez
standards, ça fait très longtemps que je n'utilise plus unstable ni
testing pour me contenter de stable (et un peu de backports lorsque
nécessaire). Mais j'en avais conclu (avis perso) qu'il fallait proscrire
les mises-à-jour globales sans vérifier auparavant tous les bugs. Du
coup j'ai gardé cette habitude en stable et le plus simple, selon moi,
c'est apt-listbugs: installé il empêche les mises-à-jour des paquets
bugués, il faut les forcer manuellement si l'on estime que les bugs en
question des paquets concernés ne sont pas gênants pour sa propre
utilisation.

Re: Actualizar OpenGL

[Camaleón]

El 2020-05-06 a las 19:39 +0200, Imeneo Tirinto escribió:

> On Wed, May 6, 2020 at 7:15 PM Camaleón  wrote:
> 
> > El 2020-05-06 a las 18:01 +0200, Imeneo Tirinto escribió:

(...)

> > > > El 2020-05-06 a las 10:20 +0200, Imeneo Tirinto escribió:
> > > >
> > > > > Necesito actualizar a la versión 3.3 o superior de OpenGl para poder
> > > > > utilizar un programa. Actualmente estoy en Debian Buster, y con
> > OpenGL
> > > > 2.2.
> > > > > He buscado por Google pero no he encontrado la manera de actualizar
> > a la
> > > > > versión que necesito.
> > > >
> > > > Normalmente, la versión de GLX está vinculada (depende) del driver que
> > > > tengas instalado para tu gráfica y de sus capacidades (tanto de
> > > > hardware como de software).
> > > >
> > > > Si nos dices qué gráfica tienes y qué driver has instalado, mejor.
> > > >
> > > > ¿Qué te devuelve esta orden?
> > > >
> > > > sm01@stt008:~$ grep -i level /var/log/Xorg.0.log
> > > > [16.687] (==) NOUVEAU(0): Allowed maximum DRI level 2.
> > > > [16.863] (==) NOUVEAU(G0): Allowed maximum DRI level 2.
> > > >
> >
> > > El log de Xorg no está en la ruta que indicas, la tengo en
> > > /home/usuario/.local/share/Xorg y devuelve lo siguiente
> > > *[  1600.219] (II) modeset(0): Analog Display Input,  Input Voltage
> > Level:
> > > 0.700/0.700 V*
> >
> > Hum... qué ruta más extraña >:-)
> >
> > Pues entonces prueba con:
> >
> > grep -i -e glx -e dri $HOME/.local/share/Xorg/*.0.log

(...)

> Lo que sale es lo siguiente
> 
(...)

> [  1600.155] (II) LoadModule: "glx"
> [  1600.156] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
> [  1600.158] (II) Module glx: vendor="X.Org Foundation"

> [  1600.160] (II) modesetting: Driver for Modesetting Kernel Drivers: kms

> [  1600.160] (II) modeset(0): using drv /dev/dri/card0

> [  1600.188] (II) modeset(0): glamor X acceleration enabled on Mesa DRI 
> Intel(R) Ironlake Desktop
> [  1600.256] (II) modeset(0): [DRI2] Setup complete
> [  1600.256] (II) modeset(0): [DRI2]   DRI driver: i965
> [  1600.256] (II) modeset(0): [DRI2]   VDPAU driver: i965
> [  1600.262] (II) Initializing extension DRI3
> [  1600.262] (II) Initializing extension GLX
> [  1600.273] (II) AIGLX: Loaded and initialized i965
> [  1600.273] (II) GLX: Initialized DRI2 GL provider for screen 0
> [  1600.273] (II) Initializing extension XFree86-DRI
> [  1600.273] (II) Initializing extension DRI2

Hasta aquí todo parece correcto.
Gráfica intel, KMS habilitado, carga la aceleración (GLX y DRI2/3) y 
Glamour. La versión de MESA que tienes instala (18.3.6x) admite OpenGL 
3.x sin problemas¹. 

No dices qué error te da exactamente la aplicación que quieres ejecutar 
pero si no te funciona o te pide una versión superior de OpenGL quizá 
sea debido a que tu tarjeta ya no lo admite. Esta tabla² te puede 
servir de guía.

Si ejecutas «glxinfo | grep "version"» (paquete mesa-utils)  te dirá tu
versión actual de OpenGL, que atendiendo a la tabla anterior debería ser
la 2.1 o 2.0.

¹ https://www.mesa3d.org/faq.html 
² https://wiki.gentoo.org/wiki/Intel#Hardware_detection

Saludos,

-- 
Camaleón 

Re: Debian testing ou stable ?

[Haricophile]

Le Tue, 5 May 2020 19:18:01 +0200,
Francois Meyer  a écrit :

> Bonjour à tous,
> 
> Je dois installer debian sur une nouvelle machine (neuve, récente). Je 
> me demandais l'intérêt et les invonvénients éventuels d'installer 
> testing plutôt que stable. Auparavant, j'ai toujours utilisé des 
> versions 'stable' (<= jessie)

Stable = maximum de sécurité et minimum de maintenance.
 
> Intérêt : quelques fonctionnalités supplémentaires, 
Ça dépend de l'usage. Tu peux avoir besoin d'un logiciel récent, c'est
généralement plutôt côté applicatif que ça se passe (par exemple Musescore
pour moi) en sachant que la stabilité est moins importante pour un desktop
personnel. 

> peut-être un meilleur fonctionnement sur une machine récente ?
Ça peut arriver pour la gestion d'un nouveau type de matériel.
 
> Inconvénients : je ne sais pas ? les bogues sont-ils si graves ?
Debian unstable c'est généralement des paquets de version pour l'upstream
intégrés mais pas encore bichonnés par Debian. C'est très utilisable
sur ton ordinateur perso au même titre qu'une distribution "rolling" et en
sachant que tu risque plus de soucis avec des paquets pour des usages moins
fréquents (par exemple Musescore...). Il faut aussi savoir lire au moment
des mises à jour et ne pas forcer les choses sans savoir ce que tu fait et
parfois jouer un peu avec le gestionnaire de paquet.

Debian testing est un cas particulier, car il s'agit de tester
l'intégration des paquets. Donc tu peux potentiellement être coincé assez
longtemps si tu ne fait pas quelques incursions avec des paquets de
unstable.

Côté sécurité, seule Stable est bichonnée par les équipes en charges.
Testing et Unstable ne sont pas prioritaires, et unstable risque d'être
corrigée plus vite que testing parce qu'elle reçoit beaucoup plus vite les
nouveautés.

Expérimental n'est pas une version, c'est les paquets bruts qui arrivent
dans Debian.

Dans tout ça il faut comprendre que chaque version a son rôle précis dans
le cycle de vie de Debian :

- Stable est la version de production
- Testing sert à fabriquer la stable
- Unstable sert a intégrer les nouveautés avant de les passer dans Testing
- Experimental reçoit les nouveaux paquets bruts et des paquets qui ne
  seront peut-être jamais intégrés.

L'utilisation de Testing ou Unstable comme version de production n'est pas
ni l'objectif ni la préoccupation des équipes de Debian, donc tu le fait en
sachant ce que tu fais. Dans la pratique pour ton ordinateur perso ça
marche très bien, mais si tu équipe un serveur, ta boite ou ta belle mère:
reste en stable.

Re: Debian testing ou stable ?

[Haricophile]

Le Tue, 5 May 2020 19:44:10 +0200,
Belaïd  a écrit :

> Pour ce genre de question, j'imagine toujours  ce que donnerait un système
> embarqué en cours de développement (Testing, unstable ...) installé dans
> un avion de ligne ! 


Eh bien grâce à Boing, nous savons !

Re: Some applications fail to pass links to browser

[Johann Klammer]

On 05/06/2020 12:00 PM, Gernot Kranz wrote:
> Hey,
> as this issue: https://github.com/wireapp/wire-desktop/issues/3853
> happens since the upgrade to debian stable (4.19.98-1+deb10u1 to be precise) 
> with at least two different programms, wire-desktop and owncloud-client, I 
> guess it is a problem in debian or lxde.
> lxde version is lxde-core_10_all.deb from debian stable.
> The problem does not happen when opening a link from evolution or
> thunderbird. Telegram and Libreoffice are affected.
> 
> How do I find out, which packages create this bug?
> 
> Gernot
> 

was having the same probs for years. 
Here, it's usually 
'fork(): Cannot allocate memory'

Some change in the kernels mem mgmt, I think.
copy the url works.

(look in .xsession-errors. it's where all the error messages go)

Re: Actualizar OpenGL

[Imeneo Tirinto]

Lo que sale es lo siguiente

[  1600.146] X.Org Video Driver: 24.0
[  1600.146] X.Org XInput driver : 24.1
[  1600.151] (II) xfree86: Adding drm device (/dev/dri/card0)
[  1600.152] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 12
paused 0
[  1600.155] (II) LoadModule: "glx"
[  1600.156] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[  1600.158] (II) Module glx: vendor="X.Org Foundation"
[  1600.158] (==) Matched modesetting as autoconfigured driver 0
[  1600.158] (==) Matched fbdev as autoconfigured driver 1
[  1600.158] (==) Matched vesa as autoconfigured driver 2
[  1600.158] (==) Assigned the driver to the xf86ConfigLayout
[  1600.158] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[  1600.158] Module class: X.Org Video Driver
[  1600.158] ABI class: X.Org Video Driver, version 24.0
[  1600.158] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[  1600.159] Module class: X.Org Video Driver
[  1600.159] ABI class: X.Org Video Driver, version 24.0
[  1600.159] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[  1600.160] Module class: X.Org Video Driver
[  1600.160] ABI class: X.Org Video Driver, version 24.0
[  1600.160] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[  1600.160] (II) FBDEV: driver for framebuffer: fbdev
[  1600.160] (II) VESA: driver for VESA chipsets: vesa
[  1600.160] (II) modeset(0): using drv /dev/dri/card0
[  1600.161] ABI class: X.Org Video Driver, version 24.0
[  1600.188] (II) modeset(0): glamor X acceleration enabled on Mesa DRI
Intel(R) Ironlake Desktop
[  1600.256] (II) modeset(0): [DRI2] Setup complete
[  1600.256] (II) modeset(0): [DRI2]   DRI driver: i965
[  1600.256] (II) modeset(0): [DRI2]   VDPAU driver: i965
[  1600.262] (II) Initializing extension DRI3
[  1600.262] (II) Initializing extension GLX
[  1600.273] (II) AIGLX: Loaded and initialized i965
[  1600.273] (II) GLX: Initialized DRI2 GL provider for screen 0
[  1600.273] (II) Initializing extension XFree86-DRI
[  1600.273] (II) Initializing extension DRI2
[  1600.352] Module class: X.Org XInput Driver
[  1600.352] ABI class: X.Org XInput driver, version 24.1
[  1600.352] (II) Using input driver 'libinput' for 'Power Button'
[  1600.384] (II) Using input driver 'libinput' for 'Power Button'
[  1600.390] (II) Using input driver 'libinput' for 'PIXART USB OPTICAL
MOUSE'
[  1600.399] (II) No input driver specified, ignoring this device.
[  1600.400] (II) Using input driver 'libinput' for 'SEM USB Keyboard'
[  1600.407] (II) Using input driver 'libinput' for 'SEM USB Keyboard
Consumer Control'
[  1600.414] (II) Using input driver 'libinput' for 'SEM USB Keyboard
System Control'
[  1600.421] (II) No input driver specified, ignoring this device.
[  1600.421] (II) No input driver specified, ignoring this device.
[  1600.422] (II) No input driver specified, ignoring this device.
[  1600.422] (II) No input driver specified, ignoring this device.
[  1600.423] (II) No input driver specified, ignoring this device.
[  1600.423] (II) No input driver specified, ignoring this device.
[  1600.429] (II) Using input driver 'libinput' for 'SEM USB Keyboard
Consumer Control'
[  1600.429] (**) Option "_source" "_driver/libinput"



El ordenador (y la gráfica) ya tiene algunos años. Pero va bien y desde que
le instalé Debian mucho mejor, más ágil.

Gracias por la ayuda.

Saludos.

On Wed, May 6, 2020 at 7:15 PM Camaleón  wrote:

> El 2020-05-06 a las 18:01 +0200, Imeneo Tirinto escribió:
>
> > Hola.
>
> Corrijo el top-posting.
>
> > On Wed, May 6, 2020 at 12:09 PM Camaleón  wrote:
> >
> > > El 2020-05-06 a las 10:20 +0200, Imeneo Tirinto escribió:
> > >
> > > > Necesito actualizar a la versión 3.3 o superior de OpenGl para poder
> > > > utilizar un programa. Actualmente estoy en Debian Buster, y con
> OpenGL
> > > 2.2.
> > > > He buscado por Google pero no he encontrado la manera de actualizar
> a la
> > > > versión que necesito.
> > >
> > > Normalmente, la versión de GLX está vinculada (depende) del driver que
> > > tengas instalado para tu gráfica y de sus capacidades (tanto de
> > > hardware como de software).
> > >
> > > Si nos dices qué gráfica tienes y qué driver has instalado, mejor.
> > >
> > > ¿Qué te devuelve esta orden?
> > >
> > > sm01@stt008:~$ grep -i level /var/log/Xorg.0.log
> > > [16.687] (==) NOUVEAU(0): Allowed maximum DRI level 2.
> > > [16.863] (==) NOUVEAU(G0): Allowed maximum DRI level 2.
> > >
>
> > El log de Xorg no está en la ruta que indicas, la tengo en
> > /home/usuario/.local/share/Xorg y devuelve lo siguiente
> > *[  1600.219] (II) modeset(0): Analog Display Input,  Input Voltage
> Level:
> > 0.700/0.700 V*
>
> Hum... qué ruta más extraña >:-)
>
> Pues entonces prueba con:
>
> grep -i -e glx -e dri $HOME/.local/share/Xorg/*.0.log
>
> > De todas formas ejecuté también "lscpi -v" y sale lo siguinte
> >
> >
> > *00:02.0 VGA compatible controller: Intel Corporation Core Processor
> > Integrated Graphics Controller (rev 12) (prog-if 00 [VGA 

Re: Actualizar OpenGL

[Camaleón]

El 2020-05-06 a las 18:01 +0200, Imeneo Tirinto escribió:

> Hola.

Corrijo el top-posting.
 
> On Wed, May 6, 2020 at 12:09 PM Camaleón  wrote:
> 
> > El 2020-05-06 a las 10:20 +0200, Imeneo Tirinto escribió:
> >
> > > Necesito actualizar a la versión 3.3 o superior de OpenGl para poder
> > > utilizar un programa. Actualmente estoy en Debian Buster, y con OpenGL
> > 2.2.
> > > He buscado por Google pero no he encontrado la manera de actualizar a la
> > > versión que necesito.
> >
> > Normalmente, la versión de GLX está vinculada (depende) del driver que
> > tengas instalado para tu gráfica y de sus capacidades (tanto de
> > hardware como de software).
> >
> > Si nos dices qué gráfica tienes y qué driver has instalado, mejor.
> >
> > ¿Qué te devuelve esta orden?
> >
> > sm01@stt008:~$ grep -i level /var/log/Xorg.0.log
> > [16.687] (==) NOUVEAU(0): Allowed maximum DRI level 2.
> > [16.863] (==) NOUVEAU(G0): Allowed maximum DRI level 2.
> >

> El log de Xorg no está en la ruta que indicas, la tengo en
> /home/usuario/.local/share/Xorg y devuelve lo siguiente
> *[  1600.219] (II) modeset(0): Analog Display Input,  Input Voltage Level:
> 0.700/0.700 V*

Hum... qué ruta más extraña >:-)

Pues entonces prueba con:

grep -i -e glx -e dri $HOME/.local/share/Xorg/*.0.log
 
> De todas formas ejecuté también "lscpi -v" y sale lo siguinte
> 
> 
> *00:02.0 VGA compatible controller: Intel Corporation Core Processor
> Integrated Graphics Controller (rev 12) (prog-if 00 [VGA controller])
> Subsystem: Foxconn International, Inc. Core Processor Integrated Graphics
> Controller Flags: bus master, fast devsel, latency 0, IRQ 27 Memory at
> fb80 (64-bit, non-prefetchable) [size=4M] Memory at d000 (64-bit,
> prefetchable) [size=256M] I/O ports at cc00 [size=8] [virtual] Expansion
> ROM at 000c [disabled] [size=128K] Capabilities: [90] MSI: Enable+
> Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2
> Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 Kernel
> modules: i915*

Siendo una gráfica intel te debería cargar todo lo relativo a la 
aceleración por hardware (glx/dri) automáticamente. Quizá 
sea una gráfica antigua y no admita una versión moderna de OpenGL.

Saludos,

-- 
Camaleón 

Re: Looking for video card recommendation

[Alberto Sentieri]

Thanks. Adding contrib solved the problem.

On 5/5/20 8:24 PM, Alexander V. Makartsev wrote:

On 05.05.2020 20:29, Alberto Sentieri wrote:
Last time I installed it I downloaded the driver from NVIDIA web 
site. I was able to install it and it worked well, but updates 
started bothering me. Maybe I should have tried a Debian repo, but I 
did not and I have no recollection of the reason.


Anyway, I was trying to install it now using debian repos (deb 
http://deb.debian.org/debian/ buster main non-free), as you 
suggested, and I got this. Any suggestion?


# nvidia-detect
Detected NVIDIA GPUs:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119 
[NVS 310] [10de:107d] (rev a1)


Checking card:  NVIDIA Corporation GF119 [NVS 310] (rev a1)
Your card is only supported up to the 390 legacy drivers series.
It is recommended to install the
    nvidia-legacy-390xx-driver
package.
# apt-get install nvidia-legacy-390xx-driver
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 nvidia-legacy-390xx-driver : PreDepends: nvidia-installer-cleanup 
but it is not installable
  Depends: 
nvidia-legacy-390xx-driver-libs (= 390.116-1) but it is not going to 
be installed or
nvidia-legacy-390xx-driver-libs-nonglvnd (= 390.116-1) but it is not 
going to be installed
  Depends: nvidia-legacy-390xx-driver-bin 
(= 390.116-1) but it is not going to be installed
  Depends: 
xserver-xorg-video-nvidia-legacy-390xx (= 390.116-1) but it is not 
going to be installed
  Depends: 
nvidia-legacy-390xx-vdpau-driver (= 390.116-1) but it is not going to 
be installed
  Depends: 
nvidia-legacy-390xx-alternative (= 390.116-1) but it is not going to 
be installed
  Depends: 
nvidia-legacy-390xx-kernel-dkms (= 390.116-1) but it is not going to 
be installed or

nvidia-legacy-390xx-kernel-390.116
  Depends: nvidia-support but it is not 
installable
  Recommends: 
nvidia-settings-legacy-390xx but it is not installable
  Recommends: libnvidia-legacy-390xx-cfg1 
(= 390.116-1) but it is not going to be installed
  Recommends: nvidia-persistenced but it 
is not installable

E: Unable to correct problems, you have held broken packages.



Package "nvidia-installer-cleanup" is in "contrib" section, so you 
have to add it too. Don't forget to invoke "apt update" after that.



--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀https://www.debian.org
⠈⠳⣄

Re: [HS] Re: Coup de gueule - Bannissement du wiki et du forum debian-fr.xyz

[Jean-Philippe MENGUAL]

Le 06/05/2020 à 17:11, G2PC a écrit :



Petite nuance hors-sujet de ce fil: si on aide une équipe, la règle de
l'ancienneté reste appliquée, donc il est vrai que si un nouveau vient
avec un refus d'admettre que d'autres le corrigent, ça clash vite.
Mais ça c'est juste logique: on se moule d'abord à l'existant avant de
le faire évoluer en douceur dans le dialogue, donc au début, on
accepte ce que dit un ancien car il le fait dans la bienveillance et
dans un souci de cohérence entre l'ensemble de ce que gère l'équipe.

Désolé c'est long, mais je trouvais utile de rappeler laphilosophie de
contribution à Debian, quoiqu'en fassent ses communautés satellites,
car ça valorise l'intérêt qu'on contribue au projet originel.


Je comprend bien, et, je n'impose rien via mon égo surdimensionné ;)


Eh bien bienvenue chez Debian alors, mais peut-être davantage au coeur 
que dans ses satellites


J'ai fait cet apartée car un contributeur a pas mal secoué une des 
équipes de travail dans Debian, refusant leurs retours car "c'est du 
chipotage", et provoquant un découragement général et, au final, le 
sien. Donc je parlais en général




Pour te l'assurer, je peux te garantir que j'avais il y a plusieurs
mois, initié un message sur le forum, pour demander à participer sur le
wiki, pour corriger certaines erreurs de mise en forme, et, pour
contribuer au contenu.

Je ne suis donc pas venu avec de gros sabots, pour mettre en place des
publicités commerciales et polluer le wiki de debian-fr.xyz


Super, toute contribution nous fait plaisir chez Debian, c'est les 
conflits d'ego qui nous mettent mal à l'aise




Lors de ce problème de censure, il m'a été reproché de contribuer en
sourçant l'apport vers une page plus complète que le wiki debian-fr.xyz.
Pourtant, c'est bien car je suis conscient que le wiki debian-fr.xyz est
consulté, que j'ai souhaité améliorer le contenu, pour proposer un
exemple, au plus complet, d'un serveur SSH.
Il est dommage qu'une communauté en place, se prive d'un tel apport,
comme je l'ai déjà justifié. Je ne pense pas être le seul "
administrateur " qui doive faire de nombreuses recherches, pour obtenir
du contenu pertinent.


Ainsi va de la vie communautaire, chacune ayant ses personnalités et sa 
conception de ses règles



Ma démarche consistait à apporter de la pertinence à l'information
partagée sur le wiki de debian-fr.xyz


C'est peut-être pas le bon endroit vu la manière dont elle a été accueillie



Je ne m'attendais pas à une médaille en chocolat ni à une prime de Noël
en contribuant, en ajoutant un exemple de configuration de serveur SSH,
avec un commentaire de une ligne (synthétique) par directive configurée.
Je ne m'attendais pas non plus à un bannissement, du fait de ma
contribution.


J'entends. On vit tous des déceptions en contribuant. Mais certains 
endroits sont plus ouverts que d'autres




Quoi qu'il en soit, j'ai maintenant bien partagé cette proposition
d'exemple pour un serveur SSH, sur l'un des wiki officiel de la
communauté Debian.


Excellent, merci!


Je remercie les personnes qui m'ont répondu avec bienveillance.

La prochaine publication sur le wiki de debian sera certainement un
exemple de configuration en français, sur le même principe, pour le
programme DenyHosts.


Merci d'avance

Amicalement,


Bonne fin de journée.

Re: debian testing, kernel 5.6 et nvidia optimus

[Jérémy Prego]

bonjour,

Le 05/05/2020 à 15:18, didier gaumet a écrit :
> ta mise à jour a-t-elle bien mis les kernel-headers ou kernel-source en 5.6?

> oui. linux-image, linux-headers, linux-headers-common, linux-kbuild, etc 
> etc... 

> sinon d'après ce que j'ai compris tu pourrais tester (ça ne mange pas de
> pain) le paquet mate-optimus à la place de bbswitch
visiblement, ça ne semble pas fonctionner, il ne trouve pas ce qu'il faut:
  - nvidia-settings and prime-select not detected.
mate-optimus-applet: NVIDIA Optimus is not supported.
du coup, il doit lui falloir les drivers proprio...

>
> sinon le wiki Archlinux sur Optimus semble assez complet quant aux
> possibilités qui te sont offertes:
>  https://wiki.archlinux.org/index.php/NVIDIA_Optimus

j'avais bien vu cette page, mais je vois pas grand chose qui pourrait
m'aider ...
> et la page Nouveau:
>  https://wiki.archlinux.org/index.php/Nouveau
ici, l'option prime est interressante, mais sous debian, ça ne semble
fonctionner qu'avec les driver proprio ...

après, est-ce que c'est normal que bbswitch ne se compile plus en 5.6,
ça j'ai pas trouvé de réponse efficace sur le sujet ... peut être ouvrir
un rapport de bug ... parce que même si ça fonctionnait pas très bien,
ça avait au moins le mérite de permettre à la carte de rester endormi
aussi longtemps qu'on y touchait pas.

merci pour vos réponses en tout cas si vous avez une idée sur le sujet.
Jerem

Re: Actualizar OpenGL

[Imeneo Tirinto]

Hola.

El log de Xorg no está en la ruta que indicas, la tengo en
/home/usuario/.local/share/Xorg y devuelve lo siguiente
*[  1600.219] (II) modeset(0): Analog Display Input,  Input Voltage Level:
0.700/0.700 V*

De todas formas ejecuté también "lscpi -v" y sale lo siguinte












*00:02.0 VGA compatible controller: Intel Corporation Core Processor
Integrated Graphics Controller (rev 12) (prog-if 00 [VGA controller])
Subsystem: Foxconn International, Inc. Core Processor Integrated Graphics
Controller Flags: bus master, fast devsel, latency 0, IRQ 27 Memory at
fb80 (64-bit, non-prefetchable) [size=4M] Memory at d000 (64-bit,
prefetchable) [size=256M] I/O ports at cc00 [size=8] [virtual] Expansion
ROM at 000c [disabled] [size=128K] Capabilities: [90] MSI: Enable+
Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 Kernel
modules: i915*


On Wed, May 6, 2020 at 12:09 PM Camaleón  wrote:

> El 2020-05-06 a las 10:20 +0200, Imeneo Tirinto escribió:
>
> > Necesito actualizar a la versión 3.3 o superior de OpenGl para poder
> > utilizar un programa. Actualmente estoy en Debian Buster, y con OpenGL
> 2.2.
> > He buscado por Google pero no he encontrado la manera de actualizar a la
> > versión que necesito.
>
> Normalmente, la versión de GLX está vinculada (depende) del driver que
> tengas instalado para tu gráfica y de sus capacidades (tanto de
> hardware como de software).
>
> Si nos dices qué gráfica tienes y qué driver has instalado, mejor.
>
> ¿Qué te devuelve esta orden?
>
> sm01@stt008:~$ grep -i level /var/log/Xorg.0.log
> [16.687] (==) NOUVEAU(0): Allowed maximum DRI level 2.
> [16.863] (==) NOUVEAU(G0): Allowed maximum DRI level 2.
>
> Saludos,
>
> --
> Camaleón
>
>

-- 
Imeneo
http://cousasdeimeneo.net/
http://twitter.com/cousasdeimeneo

Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?

[Pierre Malard]

Ouahh, que de bonnes questions !

> Le 6 mai 2020 à 17:14, G2PC  a écrit :
> 
> Comment mettre à jour un fichier appartenant à l'utilisateur root avec
> cron ?
> 
> Bonjour, je cherche à mettre à jour le fichier deny.hosts proposé par
> securityinfo, chaque semaine.
> 
> Je pourrais le faire en utilisant une tache cron, avec l'utilisateur root.
> Je ne sais pas si c'est la meilleur façon de faire, utiliser root pour
> lancer une tache cron, pour télécharger un fichier qui appartiendra à
> root:root par défaut.
> 
> Faudrait t'il utiliser un autre utilisateur, sudoers ?
> 
> Ou encore, un simple utilisateur, avec des droits particuliers pouvant
> écrire ce fichier deny.hosts (qui appartient à root:root par défaut ?
> 
> 
> Comment feriez vous ?
> 
> Au plus simple, utiliser une tâche cron avec l'utilisateur root semble
> rapide et fonctionnel, mais, est ce le plus adapté en ce qui concerne la
> sécurité et les bonnes pratiques ?

Effectivement, il y a des questions à se poser quand on utiliser
l’utilisateur « root ». Mais là, dans ce cas, si je comprends bien
tu cherche à modifier un fichier « système » qui appartient
effectivement à … « root » avec un script que tu lanceras de ce même
serveur à partir d’un appel système géré par … « root » (cron) pour
contraindre les accès à ton serveur.
Donc, dans ce cas précis et si ton script est bien écrit et n’ouvre
pas trop les vannes (umask, droits d’exécution, …) je ne vois aucune
contre-indication à le lancer « root ».
Si tu veux mettre ceinture et bretelles, test dans ton script que
c’est bien le processus de gestion des CRON qui appelle ton script…

Donc, pour résumer, voici ce que je ferais :
- script ayant les droits de root soit par héritage sudo, soit
  directement sur l’ID appelant. Vérification que le père d’appel
  du script est bien « cron ».
- exécution du script dans le /etc/cron.d avec les droits de root

Bonne soirée

--
Pierre Malard

  « Les utopies ne sont souvent que des vérités prématurées »
  Alphonse de Lamartine
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?

[Cyrille BIOT]

Bsr,
Si tout appartient à root, je pense que le plus simple est d'utiliser  
simplement la crontab root.
Mais ce n'est que mon avis... Mais pourquoi faire simple quand on peut  
faire compliqué Ou l'inverse, je ne sais plus trop... ;)

Cdt
Cyrille

Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?

[Basile Starynkevitch]

On 5/6/20 5:14 PM, G2PC wrote:

Comment mettre à jour un fichier appartenant à l'utilisateur root avec
cron ?

Comment feriez vous ?



Je lirais d'abord /Advanced Linux Programming/ 
, la section 2 
 des pages de man en commençant 
par intro(2)  et 
syscalls(2)  puis 
execve(2)  et aussi 
credentials(7) 


La page wikipedia sur Setuid  est 
très instructive et importante et elle complète utilement les lectures 
précédentes.


Il peut aussi être utile de lire un cours sur les systèmes 
d'exploitation. Celui-ci  est en 
ligne, mais en anglais. Je le trouve excellent.



Je pourrais le faire en utilisant une tache cron, avec l'utilisateur root.
Je ne sais pas si c'est la meilleure façon de faire, utiliser root pour
lancer une tache cron, pour télécharger un fichier qui appartiendra à
root:root par défaut.



*Ça veut dire quoi, **/meilleure façon de faire?/*

*/
/*

Tu as oublié encore une fois d'expliciter en français le principal: 
*quels sont tes critères?* Le coût? Le temps que tu y passes? La 
cybersécurité?


(c'est la même critique que sur l'envoi de SMS gratuitement: rien n'est 
gratuit sur terre, si tu comptes ton temps et tes compétences et ton 
envie d'apprendre).



En particulier, *que se passe-t-il si ça merde d'une manière ou d'une 
autre?* Une guerre nucléaire? Une pandémie mondiale? Une catastrophe 
boursière? cent personnes qui perdent leur emploi? Ou juste toi qui 
perds une demi-heure de ton temps?


A combien de kiloeuros estimes tu la perte de ce fichier?

Librement

--
Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France; 
(mobile phone: cf my web page / voir ma page web...)

Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?

[ajh-valmer]

On Wednesday 06 May 2020 17:14:24 G2PC wrote:
> Comment mettre à jour un fichier appartenant à l'utilisateur root avec
> cron ?
...

En créant un crontab sous le compte root.
# crontab -e

Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?

[G2PC]

Comment mettre à jour un fichier appartenant à l'utilisateur root avec
cron ?

Bonjour, je cherche à mettre à jour le fichier deny.hosts proposé par
securityinfo, chaque semaine.

Je pourrais le faire en utilisant une tache cron, avec l'utilisateur root.
Je ne sais pas si c'est la meilleur façon de faire, utiliser root pour
lancer une tache cron, pour télécharger un fichier qui appartiendra à
root:root par défaut.

Faudrait t'il utiliser un autre utilisateur, sudoers ?

Ou encore, un simple utilisateur, avec des droits particuliers pouvant
écrire ce fichier deny.hosts (qui appartient à root:root par défaut ?


Comment feriez vous ?

Au plus simple, utiliser une tâche cron avec l'utilisateur root semble
rapide et fonctionnel, mais, est ce le plus adapté en ce qui concerne la
sécurité et les bonnes pratiques ?

Re: [HS] Re: Coup de gueule - Bannissement du wiki et du forum debian-fr.xyz

[G2PC]

> Petite nuance hors-sujet de ce fil: si on aide une équipe, la règle de
> l'ancienneté reste appliquée, donc il est vrai que si un nouveau vient
> avec un refus d'admettre que d'autres le corrigent, ça clash vite.
> Mais ça c'est juste logique: on se moule d'abord à l'existant avant de
> le faire évoluer en douceur dans le dialogue, donc au début, on
> accepte ce que dit un ancien car il le fait dans la bienveillance et
> dans un souci de cohérence entre l'ensemble de ce que gère l'équipe.
>
> Désolé c'est long, mais je trouvais utile de rappeler laphilosophie de
> contribution à Debian, quoiqu'en fassent ses communautés satellites,
> car ça valorise l'intérêt qu'on contribue au projet originel.

Je comprend bien, et, je n'impose rien via mon égo surdimensionné ;)
Pour te l'assurer, je peux te garantir que j'avais il y a plusieurs
mois, initié un message sur le forum, pour demander à participer sur le
wiki, pour corriger certaines erreurs de mise en forme, et, pour
contribuer au contenu.

Je ne suis donc pas venu avec de gros sabots, pour mettre en place des
publicités commerciales et polluer le wiki de debian-fr.xyz
Lors de ce problème de censure, il m'a été reproché de contribuer en
sourçant l'apport vers une page plus complète que le wiki debian-fr.xyz.
Pourtant, c'est bien car je suis conscient que le wiki debian-fr.xyz est
consulté, que j'ai souhaité améliorer le contenu, pour proposer un
exemple, au plus complet, d'un serveur SSH.
Il est dommage qu'une communauté en place, se prive d'un tel apport,
comme je l'ai déjà justifié. Je ne pense pas être le seul "
administrateur " qui doive faire de nombreuses recherches, pour obtenir
du contenu pertinent.
Ma démarche consistait à apporter de la pertinence à l'information
partagée sur le wiki de debian-fr.xyz

Je ne m'attendais pas à une médaille en chocolat ni à une prime de Noël
en contribuant, en ajoutant un exemple de configuration de serveur SSH,
avec un commentaire de une ligne (synthétique) par directive configurée.
Je ne m'attendais pas non plus à un bannissement, du fait de ma
contribution.

Quoi qu'il en soit, j'ai maintenant bien partagé cette proposition
d'exemple pour un serveur SSH, sur l'un des wiki officiel de la
communauté Debian.
Je remercie les personnes qui m'ont répondu avec bienveillance.

La prochaine publication sur le wiki de debian sera certainement un
exemple de configuration en français, sur le même principe, pour le
programme DenyHosts.
Bonne fin de journée.

Re: Custom application icon do not appear in Gnome and LXQT

[Yvan Masson]

Le 05/05/2020 à 20:55, Yvan Masson a écrit :

Le 05/05/2020 à 17:06, Yvan Masson a écrit :

Le 05/05/2020 à 16:48, Yvan Masson a écrit :

Le 05/05/2020 à 15:52, Yvan Masson a écrit :

Le 05/05/2020 à 12:42, Liam O'Toole a écrit :

On Mon, 04 May, 2020 at 23:02:16 +0200, Yvan Masson wrote:

Le 04/05/2020 à 22:52, Liam O'Toole a écrit :

On Mon, 04 May, 2020 at 22:29:14 +0200, Yvan Masson wrote:

Le 04/05/2020 à 22:21, Liam O'Toole a écrit :

On Mon, 04 May, 2020 at 21:22:20 +0200, Yvan Masson wrote:

Le 04/05/2020 à 17:06, Liam O'Toole a écrit :

On Mon, 04 May, 2020 at 16:28:30 +0200, Yvan Masson wrote:


That looks reasonable. Does your current icon theme inherit 
from hicolor?


Sorry I do not understand your question: I only have one icon, 
in different
sizes (plus one SVG in the "scalable" subdirectory). What I 
understand is
that Freedesktop specification says that application developpers 
should put

the icon in the hicolor directory: am I wrong or missing something?


To simplify the question: what does

  gsettings get org.gnome.desktop.interface icon-theme

say?


It says "Adwaita"



OK. Try putting your icon file in one of the Adwaita directories 
instead

of hicolor.

Thanks for the suggestion, but no change. It seems normal because 
desktop environment must fall back to hicolor theme when the icon is 
not found is the current theme (see "Installing Application Icons" 
in 
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#install_icons). 



I might have a similar issue as the one discribed on 
https://github.com/solus-project/budgie-desktop/issues/821 but I 
still need to investigate.


OK, I found a solution: I renamed my python script in /usr/local/bin 
to "libretrombi" and it works now.


I did so many tests I forgot that I won't try to find a proper 
explanation. Thanks for your suggestions!


Unfortunately there must be caching somewhere in LXQT, or I missed 
something, because after login in to Gnome again I could not see my 
icon anymore. And I see now that it does not work anymore in LXQT… :-(


I will have to make some new tests… I will let you know.

I am again in a working state: my desktop file is named 
"libretrombi.desktop", my icons "libretrombi.png", and my executable 
"libretrombi". This is good, but I want to distribute my software with 
Flatpak, which requires the use of an "application ID" (e.g. 
org.domain.myapp), so I will continue experiment.


After more experiments, still on my personal laptop, I can say that when 
my desktop file is named with an application ID (e.g. 
com.example.myapp.desktop), it works only in LXQT but not in Gnome. Very 
strange, as it works for other programs (e.g. org.gnome.Evolution.desktop).


Computer mysteries…

Re: cleanly getting rid of manually installed transitional packages due to rename

[Vincent Lefevre]

On 2020-04-28 10:21:16 -0500, David Wright wrote:
> On Sat 25 Apr 2020 at 21:41:09 (+0200), Vincent Lefevre wrote:
> > I think that you are over-optimistic. Imagine the following case.
> > The pdftk package has been manually installed in the past and is
> > now a transitional package to pdftk-java (currently, this is like
> > your example). But the system has some package that depends on
> > pdftk-java. So, when you run
> > 
> >   apt-get -s purge pdftk
> > 
> > you won't have any message about pdftk-java.
> 
> Sure, that could happen, and the solution is pretty much the same as
> getting too many packages: there's bound to be a dependent
> relationship between pdftk and whatever the replacement is.
> So in either eventuality, you would either have included that check
> in your script, or would kick yourself that you hadn't.

Well, I think that the solution is not to get the information
via "apt-get -s purge" but via "apt-cache depends". This would
be the following zsh script:

--
#!/usr/bin/env zsh

set -e

setopt EXTENDED_GLOB

if [[ $# -ne 1 ]] then
  echo "Usage: $0 " >&2
  exit 1
fi

if [[ -z "$(apt-mark showmanual $1)" ]] then
  echo "$0: package $1 is not marked as manually installed" >&2
  exit 2
fi

if ! dpkg -s $1 | grep -iq '^Description:.*transitional'; then
  echo "$0: package $1 is not a transitional package" >&2
  exit 2
fi

dep=()

apt-cache depends $1 | while read line
  do
case $line in
  \|*)
echo "$0: unexpected OR dependency, aborting" >&2
exit 2
;;
  Depends:*)
dep+=${line##Depends: #}
;;
esac
  done

for i in $dep
do
  apt-mark manual $i
done

apt purge $1
--

Note: "apt-cache depends" is multiarch-aware, i.e. it will append
the architecture when need be, which is a good thing here (and when
doing things manually, e.g. by looking at the "dpkg -s" output, it
can be easy to forget that).

> As I said, this has to be done so infrequently (in stable, at least),

I use unstable. I doubt that packages get renamed in stable
(except between full upgrades, where the issue has already
been solved with the oldlibs section).

> that I've never bothered to think about scripting it, which means
> that interactively you just deal with any corner cases as they arise.

Yes, one can do that manually. But one important issue is that one may
forget to do that and use "apt purge ..." directly without remembering
that one also needs to mark the dependencies as manually installed
(and the script does not solve this particular issue, since one may
forget to run it, at least when one has taken the habit to use
"apt purge ..." directly).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Actualizar OpenGL

[Camaleón]

El 2020-05-06 a las 10:20 +0200, Imeneo Tirinto escribió:

> Necesito actualizar a la versión 3.3 o superior de OpenGl para poder
> utilizar un programa. Actualmente estoy en Debian Buster, y con OpenGL 2.2.
> He buscado por Google pero no he encontrado la manera de actualizar a la
> versión que necesito.

Normalmente, la versión de GLX está vinculada (depende) del driver que 
tengas instalado para tu gráfica y de sus capacidades (tanto de 
hardware como de software).

Si nos dices qué gráfica tienes y qué driver has instalado, mejor.

¿Qué te devuelve esta orden?

sm01@stt008:~$ grep -i level /var/log/Xorg.0.log
[16.687] (==) NOUVEAU(0): Allowed maximum DRI level 2.
[16.863] (==) NOUVEAU(G0): Allowed maximum DRI level 2.

Saludos,

-- 
Camaleón 

Some applications fail to pass links to browser

[Gernot Kranz]

Hey,
as this issue: https://github.com/wireapp/wire-desktop/issues/3853
happens since the upgrade to debian stable (4.19.98-1+deb10u1 to be precise) 
with at least two different programms, wire-desktop and owncloud-client, I 
guess it is a problem in debian or lxde.
lxde version is lxde-core_10_all.deb from debian stable.
The problem does not happen when opening a link from evolution or
thunderbird. Telegram and Libreoffice are affected.

How do I find out, which packages create this bug?

Gernot


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

Re: Verkeerde tijd ondanks NTP

[Heiko Noordhof]

Hoi,

Net als MJ zijn wij ook op chrony overgestapt en dat bevalt heel goed. 
Duidelijker configuratie en documentatie. (om te beginnen bruikbare man 
pages)


Hoe de tijd verkeerd komt te staan weet ik niet. Maar *als* hij eenmaal 
flink verkeerd staat, hoeft het niet vreemd te zijn dat het heel lang 
duurt voor hij weer goed staat: zowel 'ntp' als 'chrony' corrigeren per 
default heel langzaam. Dit om te zorgen dat timestamps van files en log 
messages blijven kloppen. De tijd laten terug springen kan heel 
vervelend zijn in logs.


Beide daemons hebben wel een optie om de tijd toch wel sprongen te laten 
maken, eventueel alleen eenmalig bij eerste start van de deamon. Maar 
dat moet je in de config aangeven, omdat dit per default uit staat.


Verder lijkt me goed te controleren:

  - In geval van dual-boot: windows zet de hardware klok op local time, 
linux (default) op UTC. Daarmee heb ik herhaaldelijk problemen zien 
optreden, ook nog na hier al bewust van te zijn.  "timedatectl" commando 
helpt by probleemzoeken.


  - Niet beide *en* een daemon *en* cron job met ntpdate gebruiken.

  - systemd's timesync zich wel heeft uitgeschakeld (voor zover ik weet 
gaat dit trouwens wel altijd goed)


Groeten, Heiko


On 5/4/20 1:12 PM, Paul van der Vlis wrote:

Hoi,

Ik zie regelmatig servers met NTP die een helemaal verkeerde tijd geven,
dus niet paar seconden maar meer dan een uur.

Gisteren had ik het ook weer, een mailserver met Debian9 stond 1 uur en
7 minuten fout.  Na een "apt install --reinstall ntp" is de tijd dan
weer goed.

Iemand een idee wat dat is?

Ik kom er meestal achter tijdens een storing, waarbij ik dan andere
dingen aan mijn hoofd heb. Dan zie ik dat de logs een verkeerde tijd geven.

Groeten,
Paul

Re: [HS] Re: Coup de gueule - Bannissement du wiki et du forum debian-fr.xyz

[Jean-Philippe MENGUAL]

Jean-Philippe MENGUAL
Debian Developer non uploading
Community team member
Accessibility team member
debian-l10n-french team member
President of Debian France non-profit organization
Le 06/05/2020 à 00:17, G2PC a écrit :



Bonjour,

Je n'ai rien suivi au sujet, déjà pris par des sujets sociaux internes
à Debian. Je dirais juste une opinion parfaitement personnelle: si tu
es déçu de ces forums & wiki, tu peux te rabattre sur les ressources
internes à Debian ou gérées par des proches du projet. Je pense ainsi
que contribuer à wiki.debian.org, ou au wiki debian-facile, à cette
mailing, à forum.debian.net, qui reste un cercle rapproché de Debian,
te garantit audience, un process de gestion des conflits plus global
(par Debian, par une asso, etc). J'ai en mémoire, mais ça n'a rien à
voir avec ça j'espère, un canal IRC #debian-fr, qui plusieurs années
durant, a été animé par des gens peu recommandables avant une
fermeture par freenode manu militari, à la demande de Debian, pour
faire cesser le lien debian - cette communauté affreuse.

DOnc pour moi, mais ça va avec mon aversion à la dispersion dans le
libre, plus on bosse près de la source, plus on est soudé, protégé par
la communauté, par des procédures, et plus son travail est visible. Ca
n'xonère pas des conflits, mais le mécanisme de résolution est plus
partagé, le respect plus fondé sur la do-cratie, et l'impression
d'arbitraire moins présent.

Amicalement,



Merci pour les liens proposés : wiki.debian.org, le wiki debian-facile,
le forum.debian.net

J'ai déjà pu partager un article, sur le wiki.debian.org et faires
quelques propositions rudimentaires.
Voilà l'article complet que j'ai proposé sur Mod Evasive, qui est un
total copier coller de l'article que j'ai rédigé sur mon propre wiki :
https://wiki.debian.org/fr/Apache/mod_evasive

Comme dit, mon coup de gueule est surtout du au fait que la ressource
que j'ai partagée ne pouvait que répondre aux besoins des
administrateurs lecteurs.
Le fait de justifier qu'une source dans la bibliographie est un backlink
sauvage, c'est de la mauvaise fois.
J'aurais pu partager le contenu, effectivement, sur de nombreuses autres
communautés.

Cette censure est méprisante, pour mon partage, le temps de recherche,
le travail effectué, et ma volonté d'améliorer une page du wiki de cette
communauté debian-fr.xyz

J'estime que c'est bien d'avantage méprisant pour la centaine et les
milliers d'administrateurs francophones qui suivront, et, qui devront
perdre du temps pour trouver la bonne information, voir, qui devront à
leur tour, tout comme moi, reconstruire l'information car l'information
est dispersée, et qui devront, de ce fait, effectuer de très nombreuses
lectures complémentaires, pour arriver au même résultat.

Je le sais parfaitement, que mon contenu est pertinent, ce n'est pas de
la prétention.
En faisant mes recherches, j'ai bien pu me faire une idée de l'état des
lieux des tutoriels que l'ont retrouve sur la toile, et, je sais de ce
fait, que mon contenu, en français, apportait bien une valeur ajoutée.

C'est bien ça, qui me met en colère, cette fausse excuse de censurer un
contenu en parlant de backlink, alors qu'ils pointent vers un contenu
pertinent qui économisera du temps à d'autres !
Je n'ai jamais compté, à un seul moment, les backlink que je met en
place vers d'autres communautés, dont la communauté en question, qui
m'exclue pour avoir sourcé un partage.

J'ai donc suivi ton conseil, et, je suis allé compléter la page
concernant SSH, sur le wiki officiel wiki.debian.org
En espérant, cette fois, que le travail francophone ne sera pas sabordé
de l'intérieur.

Exemple de configuration SSH :
https://wiki.debian.org/fr/SSH#Exemple_fonctionnel_et_comment.2BAOk_pour_configurer_un_Serveur_SSH


Merci pour ce travail. Il ne sera pas sabordé, car Debian ne fonctionne 
pas comme ça. Qu'il y ait des sous-communautés qui le fassent, c'est un 
fait, et elles sont gérées par des gens qui en définissent les règles, 
et peuvent les appliquer de manière qui peut sembler arbitraire.


Mais ça ne relève pas de la philosophie Debian. Pour le projet Debian, 
toute initiative est bienvenue, dès lors qu'elle ne clash pas avec 
d'autres intérêts, au quel cas les deux parties discutent et, faute 
d'accord, en réfèrent à un comité (si le débat est technique) ou 
s'appuient sur le soutien des autres membres de la communauté. Le 
perdant, s'il a de l'ego, peut mal le vivre, mais il sait que sa 
position est analysée non pas arbitrairement, mais par une communauté de 
pairs bienveillants. Et ce recours n'intervient que dès lors qu'il y a 
désaccord entre le contributeur et un autre en ce qu'ils de marchent 
dessus. Typiquement, Debian admet que du non-libre fasse partie de son 
infra, mais refuse de l'inclure dans son OS officiel, c'est le fruit 
d'un ocnsensus communautaire. Souvent difficile, mais il arrive 
toujours. Et de nouveau, on peut très bien contribuer des années dans 
son coin sans le moindre débat, tant que ça ne 

Actualizar OpenGL

[Imeneo Tirinto]

Hola a todos.

Necesito actualizar a la versión 3.3 o superior de OpenGl para poder
utilizar un programa. Actualmente estoy en Debian Buster, y con OpenGL 2.2.
He buscado por Google pero no he encontrado la manera de actualizar a la
versión que necesito.

Me podríais ayudar? Gracias.

Saludos.

-- 
Imeneo
http://cousasdeimeneo.net/
http://twitter.com/cousasdeimeneo

Re: mount an external usb hdd and share it through samba

[Andrei POPESCU]

On Mi, 06 mai 20, 01:35:02, Michael Morgan wrote:
> 
> Since automount works, and samba will work well if I restart it, my guess is
> that on boot, samba (smbd service) starts before /usb-hdd is mounted. To
> make it working, 
> I need make sure the fstab mounting happens before samba starts. Can anyone
> tell me how to do it? Or, any better solution for auto mount and share a usb
> HDD?

According to systemd.mount(5) there are fstab options to force ordering 
before a specific unit.

It does seem strange that this is needed though. Could you please attach 
the smbd.service unit? Please also specify which Debian release you are 
using.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Traag reagerende computer, wat te doen?

[Paul van der Vlis]

Hoi,

Ik krijg soms de vraag waarom een laptop of computer soms traag
reageert. Of zelfs helemaal niet meer reageert. Hier wat opmerkingen
hierover.

Vaak komt dit door een webpagina die heel veel van de processor vraagt.
Soms is het ook een advertentie op die pagina.

Dit probleem is uiteraard lastig op te lossen als de computer al heel
traag is. Daarom is het vaak het beste om het "voor" te zijn,
bijvoorbeeld als je de ventilator hoort loeien.

Open dan "system monitor", een grafisch programma. Druk 2x op %CPU zodat
het proces wat het meeste CPU gebruikt bovenaan komt. Selecteer dat
proces zodat het blauw wordt. Vaak is dit dus "web content".

Interessant is het nu te weten welke web-pagina deze load geeft. Want
dan kun je er rekening mee houden, door zo'n pagina bijvoorbeeld direct
na gebruik weer te sluiten. Dat zie je hier echter jammergenoeg niet.

Wat ik dan doe is klikken op de knop die onderaan is verschenen, "proces
beeindigen", en je bevestigt dat je dat proces wilt beeindigen.

Als het gaat om webcontent zal er een tabblad in de browser crashen. Je
kunt dat zien aan een uitroepteken in het tabblad. Op de pagina
verschijnt iets van "Ach. Uw tabblad is zojuist gecrasht.". Maar nog
steeds niet duidelijk welke pagina het was. Druk daarom op "dit tabblad
herstellen" en je weet welke pagina het was. En je kunt er rekening mee
houden.

Wil je dit eens zien, ga dan bijvoorbeeld naar https://bitcoin.de , dat
is een behoorlijk zware pagina, maar ook weer niet zo erg dat alles
vastloopt. Je zult hem zien in system monitor. Daar kun je het proces
beeindigen, en weer herstellen in de browser zoals boven beschreven.

Ik denk dat de meeste mensen system monitor wel geinstalleerd hebben,
zelf heb ik "gnome-system-monitor", maar ik draai hem onder een andere
desktop. Blijkbaar geen probleem. Je hebt ook een "mate-system-monitor"
wat ongeveer hetzelfde doet. En andere desktops hebben vast iets
vergelijkbaars.

Mocht er een ander, wellicht belangrijk proces veel CPU vragen (zoals
Thunderbird), dan is het wellicht een idee om het een lagere prioriteit
te geven. Dat kun je doen met een rechter muisklik op het proces, en dan
"prioriteit wijzigen". Als je de prioriteit lager maakt dan normaal, dan
gaan andere processen voor.

Groeten,
Paul



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: mount an external usb hdd and share it through samba

[Marco Möller]

On 06.05.20 08:35, Michael Morgan wrote:

Dear all,

  


I have an external usb hdd. I would like to automount it on boot and share
it through samba.

  


1) So I put it in the fstab. It automounts correctly on boot, no problem:

UUID=XXX /usb-hdd ext4 defaults,nofail 0 0

  


2) I then share the directory "/usb-hdd" through samba (in smb.conf) after
it was mounted. No problem again:

[usb-hdd]

comment = raid5-usb

path = /usb-hdd

read only = No

valid users = michaelm

  


3) however, if the machine restarts, automounts works but the samba share
always fails. I can easily fix it by:

systemctl restart smbd

  


Since automount works, and samba will work well if I restart it, my guess is
that on boot, samba (smbd service) starts before /usb-hdd is mounted. To
make it working,
I need make sure the fstab mounting happens before samba starts. Can anyone
tell me how to do it? Or, any better solution for auto mount and share a usb
HDD?


This kind of dependencies can be added to the service unit file in 
section [Unit], in your case in the file "smbd.service"


[Unit]
RequiresMountsFor=/this/path/needs/to/be/present



Good luck,
Marco.

mount an external usb hdd and share it through samba

[Michael Morgan]

Dear all,

 

I have an external usb hdd. I would like to automount it on boot and share
it through samba.

 

1) So I put it in the fstab. It automounts correctly on boot, no problem:

UUID=XXX /usb-hdd ext4 defaults,nofail 0 0

 

2) I then share the directory "/usb-hdd" through samba (in smb.conf) after
it was mounted. No problem again:

[usb-hdd]

comment = raid5-usb

path = /usb-hdd

read only = No

valid users = michaelm

 

3) however, if the machine restarts, automounts works but the samba share
always fails. I can easily fix it by:

systemctl restart smbd 

 

Since automount works, and samba will work well if I restart it, my guess is
that on boot, samba (smbd service) starts before /usb-hdd is mounted. To
make it working, 
I need make sure the fstab mounting happens before samba starts. Can anyone
tell me how to do it? Or, any better solution for auto mount and share a usb
HDD?

 

Thank you very much.

Micahel Morgan