Re: bien configurer son .emacs

[ptilou]

Bonjour

Le vendredi 2 mars 2018 17:20:02 UTC+1, Bernard Schoenacker a écrit :
> bonjour,
> 
> désolé pour le troll poilu ...
> 
> je recherche un ensemble de .emacs à employer
> pour:
> 
> LaTeX (auctex ?)  (muktilingue et bidi)
> mh-e (mail)
> 
> c'est pour mettre le pied à l'étrier à un préadolescent précoce
> et pour moi
> 
> slt
> bernard

.vimrc, çà c'est plus sérieux tant cas faire quelque chose le faire bien

-- 
Ptilou

Re: NUC7i3DNKE + écrans qui clignotent

[Bernard Schoenacker]

bonjour,

serait il possible de faire un essai avec x2go server
et x2go client (pyHoca) ?

sources.list en pièce jointe

lien :

https://wiki.x2go.org/doku.php


slt
bernard

x2go.list
Description: Binary data

Re: NUC7i3DNKE + écrans qui clignotent

[Christophe De Natale]

Le 05/03/2018 à 18:26, JF Straeten a écrit :

[...]
Voilà, si quelqu'un y comprend quelque chose ou a des idées, je suis
preneur parce que j'y perds mes pingouins pour le moment :-)

Je remercie aussi encore ceux qui se sont penchés sur le problème.

A+


Bonjour,

Le bios ne comporte pas d'options qui aideraient ?
Sinon, toutes les tentatives le sont en ltsp ?
Pas moyen d'essayer en plus "direct" (live-cd ou clé bootable) ?
Comment être certain que le standard est respecté ou compatible sur le 
câble dvi/hdmi ?


Bon courage,

--
Christophe De Natale

Re: NUC7i3DNKE + écrans qui clignotent

[JF Straeten]

Re,

On Mon, Mar 05, 2018 at 01:45:25PM +0100, JF Straeten wrote:

[...]
> Par contre, pour ce qui est logiciel, sans charger le microcode
> Intel au démarrage de la machine, ça fait clairement sapin de Noël
> quels que soient la distri et le kernel utilisés. Ensuite, avec
> microcode, ça s'améliore jusqu'à donner les moins mauvais résultats
> avec le 4.14 de buster.

Pour renchérir sur la partie logicielle, compte tenu de ceci :

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1604819

j'ai essayé avec plus vieux et booté le NUC sur une jessie.

On est toutefois à des versions de noyau et de serveur X encore
antérieures à celles rapportées comme fonctionnelles dans ce message,
mais ça permet quand même quelques observations, aussi intéressantes
que délirantes :

- sans installer le microcode Intel, et avec un serveur X en 16 bit,
  c'est la foire totale : sapin de Noël ;

- en installant le microcode et en forçant le serveur X à 24 bit,
  c'est nettement mieux : ça ne clignote que de temps en temps ;

  NB1. je n'ai toutefois pas la preuve que le microcode est chargé, je
  ne le vois pas dans un dmesg -T (BTW, y a-t-il un autre moyen de
  vérifier ?)
  
  NB2. oui, j'ai fait le bleu en troubleshooting en faisant varier
  deux paramètres à la fois, j'en suis conscient :-)

- le serveur X semble adresser la carte avec le driver VESA, d'après
  le log ;

- enfin, en forçant le serveur X à "intel", X ne démarre pas car "No
  device found" : je pense que le pilote est trop vieux pour la
  carte ;

- et le meilleur pour la fin : quelle que soit la situation ci-dessus,
  le clignotement n'apparaît *jamais* quand il n'y a que la root
  window d'affichée. C'est au lancement de quelques rxvt (ou un
  Thunar) que ça commence à foirer. Mais en les fermant, le
  clignotement s'arrête net. Idem avec le screensaver : le lancer fait
  réapparaître l'écran, et il se lance normalement, pourvu que ça soit
  sur la root window uniquement, au terme de son délai DPMS, sans que
  ça ne foire...

  NB1. ce poste tourne sous i3, donc au lancement il n'y a qu'une
  barre de statut indiquant le n° de workspace sur la root window.


Voilà, si quelqu'un y comprend quelque chose ou a des idées, je suis
preneur parce que j'y perds mes pingouins pour le moment :-)

Je remercie aussi encore ceux qui se sont penchés sur le problème.

A+


-- 

JFS.

Re: base-files en version plus élevée sur stretch que stretch-updates

[Daniel Caillibaud]

Le 05/03/18 à 16:10, Sébastien Villemot  a écrit :
SV> Ce qui explique que deux versions semblent aujourd’hui coexister.

Merci pour l'explication !

-- 
Daniel

Si vous ne payez pas un service fourni par une entreprise sur Internet, 
c'est que vous n'êtes pas le client mais le produit vendu.


pgpOuMGj5zMSZ.pgp
Description: Signature digitale OpenPGP

Re: NUC7i3DNKE + écrans qui clignotent

[JF Straeten]

Re,

On Mon, Mar 05, 2018 at 04:19:47PM +0100, Yann Serre wrote:
> Le 05/03/2018 à 13:59, JF Straeten a écrit :
> > Les moniteurs datent de 2011 et 2012, certes, mais ce sont des DELL
> > qui coûtaient un bras, et dont j'espère donc quand même que
> > l'électronique est potable:-)  En outre, ils fonctionnent parfaitement
> > sur une autre machine, chacun seul ou les deux ensemble...
> 
> J'ai 6 Samsung qui coûtaient 6 bras dont 4 sont tombés en panne le même
> trimestre après 10 ans de bons et loyaux services. Passé à Asus depuis.

Certes, j'entends bien, mais les écrans fonctionnent parfaitement sur
un client Wyse actuellement...

Merci,

-- 

JFS.

Re: NUC7i3DNKE + écrans qui clignotent

[Yann Serre]

Le 05/03/2018 à 13:59, JF Straeten a écrit :

Les moniteurs datent de 2011 et 2012, certes, mais ce sont des DELL
qui coûtaient un bras, et dont j'espère donc quand même que
l'électronique est potable:-)  En outre, ils fonctionnent parfaitement
sur une autre machine, chacun seul ou les deux ensemble...


J'ai 6 Samsung qui coûtaient 6 bras dont 4 sont tombés en panne le même 
trimestre après 10 ans de bons et loyaux services. Passé à Asus depuis.

Re: base-files en version plus élevée sur stretch que stretch-updates

[Sébastien Villemot]

Bonjour,

On Mon, Mar 05, 2018 at 11:17:16AM +0100, Daniel Caillibaud wrote:

> https://packages.debian.org/search?searchon=names=base-files
> montre un update en version antérieure à l'original, c'est bizarre non ?
> 
> Avec les préférences apt par défaut, les deux ont la même priorité, donc
> c'est pas un drame, mais je trouve ça louche…

Cette bizarrerie est due à un accident de parcours lors de la publication de la
version 9.2 de Debian.

Comme le paquet base-files contient le fichier /etc/debian_version, celui-ci
est mis à jour à chaque nouvelle version (majeure comme mineure) de Debian. Ces
mises à jour sont normalement distribuées via la suite "stable" (en ce moment
égale à "stretch").

Mais lors de la publication de Debian 9.2, la mise à jour de base-files
(version 9.9+deb9u2) avait été oubliée (donc en particulier /etc/debian_version
contenait toujours 9.1).

Comme il était trop tard pour distribuer cette mise à jour via la suite
"stretch", la solution adoptée a été de la distribuer via "stretch-updates"
(sans attendre Debian 9.3 prévue quelques mois plus tard).

Puis, lorsque Debian 9.3 est sortie, base-files (version 9.9+deb9u3) a été mis
à jour via la suite "stretch", comme d’habitude.

Ce qui explique que deux versions semblent aujourd’hui coexister. Mais ça n’a
aucune conséquence négative en pratique, puisque c’est bien la version
9.9+deb9u3 qui est installée par apt (sauf si les priorités entre dépôts ont
été bidouillés, mais dans ce cas-là l’utilisateur est censé savoir ce qu’il
fait).

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Re: base-files en version plus élevée sur stretch que stretch-updates

[Ph. Gras]

Hello!

> Le 05/03/18 à 12:04, "Ph. Gras"  a écrit :
> PG> Salut !
> PG> 
> PG> > https://packages.debian.org/search?searchon=names=base-files
> PG> > montre un update en version antérieure à l'original, c'est bizarre
> PG> > non ?
> PG> > 
> PG> > Avec les préférences apt par défaut, les deux ont la même priorité,
> PG> > donc c'est pas un drame, mais je trouve ça louche…  
> PG> 
> PG> Lequel des 2 paquets préfèrerais-tu pour ta machine et pourquoi ?
> 
> À priori le dernier, car je fais confiance aux mainteneurs pour me dire
> qu'ils avaient une bonne raison de sortir une nouvelle version, et je laisse
> faire mon gestionnaire de paquets pour l'obtenir ;-)

C'est une bonne pratique, en effet :-)

> 
> C'est juste que je trouve bizarre qu'un paquet 9.9+deb9u2 soit classé
> comme un update de 9.9+deb9u3, je suppose que c'est une erreur dans la mise
> à jour de stretch-updates…

C'est bizarre effectivement, mais il peut y avoir au moins 2 raisons à cela :
1). La version stretch-updates (deb9u2) peut être plus ancienne que la 
version stretch
(deb9u3).
2). Des paquets couramment utilisés n'existent pas (ou plus) dans la 
version deb9u2 :
https://packages.debian.org/search?keywords=roundcube

3). D'autres raisons ou possibilités ?

Ph. Gras
Plus une discussion sur une liste dure longtemps, plus la probabilité d'y 
trouver une
comparaison impliquant les nazis ou Hitler s'approche de 1. Je veux donc 
m'arrêter
là, soit juste avant d'atteindre cette limite et d'emporter le point Godwin.

Re: NUC7i3DNKE + écrans qui clignotent

[JF Straeten]

Salut,


On Mon, Mar 05, 2018 at 09:59:13AM +0100, fab wrote:

> Tu peux essayer ta CG sur un autre poste avec 1 autre écran puis un
> second pour vérifier si c'est la carte mère qui déconne ou si c'est
> la carte graphique ?

Tout est intégré, c'est un NUC :

https://www.centralpoint.be/fr/barebones-pc-poste-de-travail/intel/nuc7i3dnke-art-blknuc7i3dnk2e-num-6960343/

Si truc déconne, tout déconne à mon humble avis...

Merci quand même,


-- 

JFS.

Re: NUC7i3DNKE + écrans qui clignotent

[JF Straeten]

Re,


On Mon, Mar 05, 2018 at 09:27:11AM +0100, err...@free.fr wrote:

[...]
> Je te conseille de tester les écrans sur d'autres machines.

Ça, ça marche : ils fonctionnent parfaitement sur un autre client
léger, tous les deux, seuls ou ensemble...

> Ou de tester avec d'autres cables.

Oui, je vais essayer...

 
> Si tu peux tester d'autres écrans sur ce NUC, c'est bien aussi.

Ça aussi...

 
> Est ce que le phénomène de clignotement persiste si tu utilise une
> résolution plus faible?

Ça aussi...


> Et si tu n'utilise qu'un seul écran?

Pareil, c'était dans le message : seuls ou à deux, même combat ;)

Merci pour le retour,


-- 

JFS.

Re: NUC7i3DNKE + écrans qui clignotent

[JF Straeten]

Re,


On Mon, Mar 05, 2018 at 08:49:30AM +0100, Yann Serre wrote:

> - la connectique (cas le plus souvent rencontré - tenter d'essuyer
> les broches ?)

Je vais essayer de changer de câble pour voir, en effet...


> - la bande passante des câbles (un câble de mauvaise qualité ou bien
> qui touche un transformateur d'alimentation qui génère des
> perturbations électro-magnétiques et le câble n'est plus capable de
> transmettre 100% du signal)

En principe, elle est bonne : l'HDMI 2.0 monte jusqu'à 4K et ça sort
en DVI-D Dual Link, nécessaire pour afficher la résolution native des
écrans de 2560x1600.

Maintenant, évidemment, la qualité des câbles, on n'en sait rien...

Voilà les câbles, identiques et neufs :

https://www.centralpoint.be/fr/c-bles-video-et-adaptateurs/manhattan/hdmi-cable-1x-hdmi-male-1x-dvi-d-24-plus-1-male-dual-link-black-1-8m-art-372503-num-5695993/


> - la carte graphique est-elle correctement ventilée ?

Elle est intégrée au CPU, c'est de l'Intel.


> si ce n'est pas une ventilation mécanique, la ventilation passive
> a-t-elle un flux d'air suffisant ?

Il y a un ventilo mécanique dans le NUC. On l'entend à fond au cold
boot et il se calme ensuite...


> (une sécurité pourrait couper brièvement l'étage de puissance de la
> carte graphique à une température maximale)

Tout est possible... Je cherche ;-)

 
> Autre problème matériel :
> - un vieux moniteur peut avoir une alimentation dont un composant a besoin
> de se stabiliser au démarrage (montée en température), avant de provoquer
> une panne d'alimentation complète dans les semaines suivantes.

Les moniteurs datent de 2011 et 2012, certes, mais ce sont des DELL
qui coûtaient un bras, et dont j'espère donc quand même que
l'électronique est potable :-) En outre, ils fonctionnent parfaitement
sur une autre machine, chacun seul ou les deux ensemble...

Merci pour le retour en tout cas,


-- 

JFS.

Re: NUC7i3DNKE + écrans qui clignotent

[JF Straeten]

Hello,


On Mon, Mar 05, 2018 at 07:46:09AM +0100, Hugues MORIN wrote:

[...]
> Il faudrai controler le materiel car ca ressemble a un probleme
> electronique (alimentation, carte video ou meme carte mere) plus que
> logiciel
> 
> C est le genre de panne galere a resoudre

En effet, mais sans exclure un souci matériel, j'inclinais plus pour
un problème logiciel...

Le matos est intégralement neuf : barebone NUC, RAM et câbles sortis
des boîtes et sachets avant les tests. Les écrans ne sont pas neufs,
mais je suis certain qu'ils fonctionnent parfaitement, tous les deux,
sur le client léger que le NUC est appelé à remplacer.

Par contre, pour ce qui est logiciel, sans charger le microcode Intel
au démarrage de la machine, ça fait clairement sapin de Noël quels que
soient la distri et le kernel utilisés. Ensuite, avec microcode, ça
s'améliore jusqu'à donner les moins mauvais résultats avec le 4.14 de
buster.

Enfin, je me dis aussi qu'un souci matériel se produirait tout le
temps, indépendamment de l'affichage, non ? Or, avec un xscreensaver
actif, ça ne le fait jamais, et avec un film jamais non plus si la
fenêtre a le focus (je l'ai surpris une fois à s'éteindre brièvement
si elle ne l'a pas).

Merci pour retour en tout cas,

-- 

JFS.

Re: base-files en version plus élevée sur stretch que stretch-updates

[Daniel Caillibaud]

Le 05/03/18 à 12:04, "Ph. Gras"  a écrit :
PG> Salut !
PG> 
PG> > https://packages.debian.org/search?searchon=names=base-files
PG> > montre un update en version antérieure à l'original, c'est bizarre
PG> > non ?
PG> > 
PG> > Avec les préférences apt par défaut, les deux ont la même priorité,
PG> > donc c'est pas un drame, mais je trouve ça louche…  
PG> 
PG> Lequel des 2 paquets préfèrerais-tu pour ta machine et pourquoi ?

À priori le dernier, car je fais confiance aux mainteneurs pour me dire
qu'ils avaient une bonne raison de sortir une nouvelle version, et je laisse
faire mon gestionnaire de paquets pour l'obtenir ;-)

C'est juste que je trouve bizarre qu'un paquet 9.9+deb9u2 soit classé
comme un update de 9.9+deb9u3, je suppose que c'est une erreur dans la mise
à jour de stretch-updates…

-- 
Daniel

Quand j'écoute trop Wagner, j'ai envie d'envahir la Pologne.
Woody Allen

Re: base-files en version plus élevée sur stretch que stretch-updates

[Ph. Gras]

Salut !

> https://packages.debian.org/search?searchon=names=base-files
> montre un update en version antérieure à l'original, c'est bizarre non ?
> 
> Avec les préférences apt par défaut, les deux ont la même priorité, donc
> c'est pas un drame, mais je trouve ça louche…

Lequel des 2 paquets préfèrerais-tu pour ta machine et pourquoi ?

Merci d'avance,

Ph. Gras

Y'a que Sun Tsu qui ait apporté un peu d'intelligence dans lard de la guerre

Re: Besoin d'aide pour interpréter erreur smartmontool

[Daysfled]

Le 04/03/18 à 19:48, Etienne Vogt a écrit :

> C'est une erreur de somme de contrôle sur le bus SATA, donc une erreur
> dans le transfert de données entre le disque et le contrôleur.
> Si cela se reproduit, essayer de changer le cable SATA, mais à priori le
> disque lui-même semble en bonne santé.
> 

Merci cela me rassure. Je surveille cela.

-- 
Days Fled

base-files en version plus élevée sur stretch que stretch-updates

[Daniel Caillibaud]

Bonjour,

https://packages.debian.org/search?searchon=names=base-files
montre un update en version antérieure à l'original, c'est bizarre non ?

Avec les préférences apt par défaut, les deux ont la même priorité, donc
c'est pas un drame, mais je trouve ça louche…

-- 
Daniel

Les avions sont des jouets sans aucune valeur militaire.
Maréchal Foch (1911)

Re: NUC7i3DNKE + écrans qui clignotent

[fab]

'lut,

Tu peux essayer ta CG sur un autre poste avec 1 autre écran puis un 
second pour vérifier si c'est la carte mère qui déconne ou si c'est la 
carte graphique ?


f.


Le 04/03/2018 à 22:03, JF Straeten a écrit :


Chère Liste,


Je me permets de vous soumettre le problème que je rencontre sur une
nouvelle machine, après avoir essayé une série de choses qui ne le
résolvent pas, en espérant que quelqu'un aurait une expérience utile
en la matière, ou déjà une idée ou deux :-)

La machine est un NUC Intel, modèle NUC7i3DNKE.

Son processeur est un Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz

Sa carte graphique, selon lspci : Intel Corporation HD Graphics 620 (rev 02)

Elle a 4GB de RAM de marque 2-Power dans le slot inférieur et est
couplée à deux écrans DELL U3011 par des câbles HDMI to DVI-D Dual
Link (ce barebone n'a que deux connecteurs HDMI 2.0). Ça fait donc 2x
2560x1600 en résolution (et il peut aller jusqu'à 2x 4k, @60 Hz).

Enfin, elle est utilisée comme client léger sous LTSP, bootant sur un
serveur LTSP en NFS, mais l'aspect LTSP est indifférent.

Question OS, a priori tout est du stretch pur jus, à jour (donc tant
le serveur LTSP que l'OS utilisé par le client léger, c.-à-d. ici le
NUC).


Le souci rencontré est que les écrans clignotent de temps en temps :
ils s'éteignent (l'un ou l'autre ou les deux) une à deux secondes,
voire parfois 4-5, et puis se rallument...

Jusqu'ici, j'ai lancé le NUC sous stretch 32bits et amd64, sans et
puis avec le microcode Intel (avec, ça améliore sensiblement les
choses, bien que ça ne soit pas encore parfait), pour finir enfin en
buster, avec le noyau 4.14.

Toujours avec le microcode, les résultats varient en fonction de la
version du noyau : avec le 4.9 de stretch, c'est inutilisable
tellement ça clignote. C'est un poil mieux avec le 4.14 des backports,
toujours en stretch et ça devient utilisable, mais encore gênant avec
le 4.14 de buster.

Pour voir, j'ai booté aussi, toujours sous buster, avec le noyau
4.15.7 de sid, mais là c'est catastrophique (et pour cause : le noyau
désactive une partie du microcode Intel en signalant qu'il ne résout
pas Spectre (j'ai oublié les termes exacts, mais le microcode est
pourtant la dernière version de chez Intel : 20171117).

Enfin, à part en 4.15.7, j'ai chaque fois essayé avec les pilotes
graphiques modesetting et Intel. On ne peut toutefois pas dire que ça
fait une différence notable de comportement, et comme modesetting est
recommandé et semble (mais c'est subjectif) un poil plus rapide à
l'affichage, je tourne avec ce pilote, sous buster pour le moment.

Enfin encore, je viens aussi d'upgrader le bios du NUC à la dernière
version (039) du 22/02/2018.

Mais même si ça n'a plus rien à voir avec les débuts sous stretch, les
clignotements persistent quand même encore, sur l'un ou l'autre des
écrans, au point que j'hésite à laisser ça comme poste de travail en
l'état...

Inverser les écrans ne change rien ; un à la fois ou deux, c'est tout
à fait pareil ; les connecteurs sont bien vissés aux écrans, etc.

Rien n'y fait : c'est totalement erratique. L'un ou l'autre s'éteint
puis se rallume, jusqu'à parfois 10x sur quelques minutes, et puis
plus rien pendant un moment, etc.

Les seuls constats qui semblent pouvoir être posés sont :

- que le phénomène ne semble jamais se produire quand l'écran change
   en permanence : en lançant xscreensaver ou un film, je ne l'ai
   jamais surpris à s'éteindre de manière inexpliquée. C'est quand
   l'image est fixe, mais qu'on tape du texte ou non, ça le fait ;

- que l'écran qui n'a pas le focus *semble* s'exciter davantage que
   celui qui contient la fenêtre où je tape ceci, mais c'est difficile
   d'en être sûr...

Voilà le phénomène bizarre. Si quelqu'un a une expérience utile à
partager ou ne fut-ce qu'une idée de piste à explorer, je suis
preneur :-)

Je vous remercie d'avance, en tout cas de m'avoir lu.

A+

Re: NUC7i3DNKE + écrans qui clignotent

[err404]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bonjour JF Straeten (Jean-François?)


Je te conseille de tester les écrans sur d'autres machines.
Ou de tester avec d'autres cables.

Si tu peux tester d'autres écrans sur ce NUC, c'est bien aussi.

Est ce que le phénomène de clignotement persiste si tu utilise une résolution 
plus faible?
Et si tu n'utilise qu'un seul écran?


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEJO//ePEJChGbGaZQrjHmR0GD/5kFAlqc/1UACgkQrjHmR0GD
/5kvYw//avDGMCEs65jz3RUKCSadspHvApTnqWWsn2Xk+/NP+Fq2vp/QAfgk4YMF
3zMflVe2XbQPCaJcHfkfzRsu7Q2bCmpp4ZvWlDKST+qBTpSG+9adOYsjRx0Keexx
CiSuW+GCO+1xERd/u8v87X+/84NyCoNzs9xcuVJI9NwKKtIWMcIkSqzDJbNbsKal
bCgA+h21QcN2Kd0tfXCmN6VwV0Hw/1tHI3RWgaXanoHgGBCAgPdr/HZKHNjgKKZ9
DZmYJJPMuLas0udHk7Z+16SFUuzvOcKRdqMfnPCXOrPMFqXTLeWRwm8E1VXvmX+L
bBLk+JuY+POXJJoubJ+UoRbtSwSJePHIRN61i8EM9pO9cnCg6t1n3KvSgsplP7Nk
8OCrbIzMwkYA1piu76fQIGIrmqKlm5DKqe2Yep0tboDzgbxD+tzIniU4MfGr/VTn
EPjlhkh5pkZv0bDVeW5e3OaZSy6nXImu+CsVXxz83PK3y1NJDWH/DpaI484w7Ec9
cGKOg85YLpZSbRBxZXTGrK6sdKMcFvgreUgK16AWTluhhhqQayeY8lNPsZtrop8L
+11IZmFkWv5DMM8hrnLT22qZCXYHxTjy3XROni5xekVYLyuaUD50FrOj/YHfXd12
kkjIIjh64eL4PTfssYeaZLiHKNYU0JVk8PlcNd3vqI3r92xXuoc=
=FVhp
-END PGP SIGNATURE-