Un peu chaud l'upgrade sid de ce soir

Support Debian
#1

Je me rends compte que je me sers de la touche backspace.
Lorsque je tape cette touce]he j’ai un ]
Le zero aussi n’est plus accessible avec shift 0 mais directement avec 0 ce qui n’est pas le comportement des autres chiffres …
Je m’arr:ete l0 car les touches mortes marchent pas mieux …
L’affichage du mappage du clavier français confirme ces dispositions.

Si vous avez quelques idees sur la question, je suis preneur :wink:

j’utilises gnome3 sur une sid amd64 (upgrade du soir …)

retour sur xfce en attendant que les choses s’améliorent …

Merci

Guy

#2

Questions bêtes (je suis encore en Wheezy, et envisage de sauter le pas d’ici quelques mois…) :
— Le soucis de disposition clavier ne se présente pas avec XFCE ?
— de manière générale, XFCE est-il plus stable que GNOME en sid ? (ceci n’est pas un troll)

Mes interrogations sur ces manips’ de clavier :
Typiquement la gestion du clavier c’est un composant de X11 qui fait ça (xkb de mémoire), j’ai du mal à comprendre pourquoi GNOME met son nez là-dedans. Ceci dit dans mes bricolages pour installer le BÉPO sur mon compte utilisateur au taf (Redhat 5.4), KDE3 fait des choses bien plus ésotériques que GNOME2 pour la gestion du multiclavier. J’ai du mal à comprendre l’intérêt de ces manips ésotériques, quelqu’un a une explication ?

#3

[quote=“guyr34”]Je me rends compte que je me sers de la touche backspace.
Lorsque je tape cette touce]he j’ai un ]
Le zero aussi n’est plus accessible avec shift 0 mais directement avec 0 ce qui n’est pas le comportement des autres chiffres …
Je m’arr:ete l0 car les touches mortes marchent pas mieux …
L’affichage du mappage du clavier français confirme ces dispositions.

Si vous avez quelques idees sur la question, je suis preneur :wink:

j’utilises gnome3 sur une sid amd64 (upgrade du soir …)

retour sur xfce en attendant que les choses s’améliorent …

Merci

Guy[/quote]

Ce soir les upgrades ne sont pas à faire tel quel sur une sid, à moins que tu souhaite tout cassé :whistle: as-tu bien regarder ce qu’il te proposé de virer, mettre à jour, installer :think:

[quote=“bobo38”]Questions bêtes (je suis encore en Wheezy, et envisage de sauter le pas d’ici quelques mois…) :
— Le soucis de disposition clavier ne se présente pas avec XFCE ?
— de manière générale, XFCE est-il plus stable que GNOME en sid ? (ceci n’est pas un troll)[/quote]

Tout dépend de ce que tu juge stable, j’ai pas de soucis, mais je prends garde à ne pas faire n’importe quoi avec les mises à jours.

[quote=“bobo38”]Mes interrogations sur ces manips’ de clavier :
Typiquement la gestion du clavier c’est un composant de X11 qui fait ça (xkb de mémoire), j’ai du mal à comprendre pourquoi GNOME met son nez là-dedans. Ceci dit dans mes bricolages pour installer le BÉPO sur mon compte utilisateur au taf (Redhat 5.4), KDE3 fait des choses bien plus ésotériques que GNOME2 pour la gestion du multiclavier. J’ai du mal à comprendre l’intérêt de ces manips ésotériques, quelqu’un a une explication ?[/quote]

Aucunes idées précises, en générales je n’ai jamais eu à bricoler pour passer le clavier en azerty avec des locales en UTF8.

#4

[quote=“bobo38”]Questions bêtes (je suis encore en Wheezy, et envisage de sauter le pas d’ici quelques mois…) :
— Le soucis de disposition clavier ne se présente pas avec XFCE ?
— de manière générale, XFCE est-il plus stable que GNOME en sid ? (ceci n’est pas un troll)

Mes interrogations sur ces manips’ de clavier :
Typiquement la gestion du clavier c’est un composant de X11 qui fait ça (xkb de mémoire), j’ai du mal à comprendre pourquoi GNOME met son nez là-dedans. Ceci dit dans mes bricolages pour installer le BÉPO sur mon compte utilisateur au taf (Redhat 5.4), KDE3 fait des choses bien plus ésotériques que GNOME2 pour la gestion du multiclavier. J’ai du mal à comprendre l’intérêt de ces manips ésotériques, quelqu’un a une explication ?[/quote]

Concernant gnome et xfce en Sid : ça doit dépendre des moments, à savoir qu’en ce moment la version d’XFCE de testing et sid est exactement la même alors que gnome (y compris gnome-shell) vient de passer en 3.8 en sid alors qu’il est resté essentiellement en 3.4 sur testing.(Donc sans avoir testé je pense qu’il y a de grandes chances pour que gnome soit plus instable/bugué que XFCE en ce moment sous Sid.)
A savoir également que la plupart du temps la liste des paquets de testing et sid est majoritairement identique (à 80-90%…peut être un peu moins en période de gel)
Perso j’ai choisi les deux, avant j’avais le dépot SID prioritaire et je bloquais les mises à jour problématique avec apt-lisbug, s’il le fallait je descendais en testing (voire stable) les paquets problématiques…mais la gestion des mises à jour me pompais vraiment trop de temps.
Depuis peu j’ai mis le dépot testing prioritaire : je descend en stable les paquets problématiques, mais je vais chercher certains paquets plus à jour en Sid (notamment iceweasel)…ce qui me semble plus reposant.

#5

Comment ça, il faut regarder ? :wink: De mon côté j’essaie de le faire (en stable c’est plus que facile), mais j’ai parfois des surprises, spécialement après avoir appuyer sur « - » dans aptitude.

Pour moi « stable en sid » signifie « pas trop de surprises et autres bugs lâchés dans la nature… pas trop de manips de cowboys », même s’il en faut sinon c’est pas drôle. En fait un bon critère pour moi serait le nombre de bugs passant les mailles du filet pour se faufiler en testing… je pense que ça peut être un bon indicateur de la force/coordination/organisation d’un « groupe de dev + communauté ».

…et là je pense qu’on peut distinguer les environnements de bureau : GNOME3, KDE, XFCE, auxquels on peut ajouter tous les forks de GNOME : Cinnamon, Mate, Unity. Dans la liste, je ne compte pas les petits qui sont souvent des gestionnaires de fenêtres, parfois boosté aux hormones, ne visant pas le même niveau d’intégration (LXDE, awesome, fluxbox, openbox, et consorts). Ils s’appuient plus volontiers sur les standards (X etc…) pour ce qui n’est pas le cœur du métier et une approche modulaire : les environnements de bureau résultants sont souvent un panaché d’outils dédiés et légers et indépendants (ce qu’on retrouve dans la philosophie de XFCE). Après ce n’est que mon point de vue, pas forcément exact.

#6

Oui il faut que je me lance dans le pinning aussi… Ce serait également mon approche de me baser sur une testing en piochant des solutions « en sid sinon en stable » pour les bugs qui se seraient faufilés. Il faudrait que je me relance sur le business, le temps libre est malheureusement une denrée rare.

#7

L’utilisation d’apt-listbugs est indispensable pour être plus serein. Cela permet de choisir si l’on installe un paquet pouvant apporter un bug, ou bien bloquer sa version temporairement.

#8

[quote=“bobo38”]
Pour moi « stable en sid » signifie « pas trop de surprises et autres bugs lâchés dans la nature… pas trop de manips de cowboys »[/quote]
Stable et sid sont deux versions différente, je ne comprends pas ce que tu veux dire par “stable en sid” (d’ailleurs sid s’appelle unstable, c’est pas pour rien).

#9

[quote=“sv0t”][quote=“bobo38”]
Pour moi « stable en sid » signifie « pas trop de surprises et autres bugs lâchés dans la nature… pas trop de manips de cowboys »[/quote]
Stable et sid sont deux versions différente, je ne comprends pas ce que tu veux dire par “stable en sid” (d’ailleurs sid s’appelle unstable, c’est pas pour rien).[/quote]

Sid -> Unstable -> veux dire surtout que ça bouge beaucoup et non pas que ça beug à mort :033 rapportez-vous à toy story pour comprendre ce que c’est SID :077

#10

Visiblement mon problème de clavier est lié 0 une conf user.
Avec un autre utilisateur je n’ai pas le pb. Un renommage du
~/.local ne suffit pas 0 régler le pb … donc ça ne vient
pas des extensions … sans doute un autre fichier de conf local.
Aucun pb sous xfce.

#11

Salut,

Faut-il encore l’utiliser à bon escient et sans pour autant le castrer, au grès des tempêtes.
Ce qui n’est pas toujours le cas … :033

#12

[quote=“Clochette”][quote=“sv0t”][quote=“bobo38”]
Pour moi « stable en sid » signifie « pas trop de surprises et autres bugs lâchés dans la nature… pas trop de manips de cowboys »[/quote]
Stable et sid sont deux versions différente, je ne comprends pas ce que tu veux dire par “stable en sid” (d’ailleurs sid s’appelle unstable, c’est pas pour rien).[/quote]

Sid -> Unstable -> veux dire surtout que ça bouge beaucoup et non pas que ça beug à mort :033 rapportez-vous à toy story pour comprendre ce que c’est SID :077[/quote]
J’ai dit ça ? Je n’ai plus le temps pour maintenir une sid, c’est pour cela que j’ai une stable avec pinning (qui était une sid en son temps), et cela me convient parfaitement.

[code]
unstable adj figurative (person: emotionally) instable, déséquilibré.

unstable adj literal (structure: unbalanced) déséquilibré.

unstable adj figurative (weather: changeable) incertain, instable, changeant,

unstable adj figurative (situation: precarious) instable, précaire.[/code]

#13

perso, j’utilise xfce donc, je n’ai pas reproduit,

mais chez moi aussi, chaud chaud la mise à jour sid d’aujourd’hui :

j’ai du me séparer de gdm3 et installer lightdm (plantage comple de X).
et j’ai du faire un dpkg-reconfigure mdadm en mode de dépannage

#14

[quote=“sv0t”][quote=“bobo38”]
Pour moi « stable en sid » signifie « pas trop de surprises et autres bugs lâchés dans la nature… pas trop de manips de cowboys »[/quote]
Stable et sid sont deux versions différente, je ne comprends pas ce que tu veux dire par “stable en sid” (d’ailleurs sid s’appelle unstable, c’est pas pour rien).[/quote]

Quand je dis « stable » c’est sans référence au « stable » de stable/testing/unstable… je n’y avais pas pensé en posant la question suivante :
« de manière générale, XFCE est-il plus stable que GNOME en sid ? (ceci n’est pas un troll) »
dans le deuxième post de ce fil, entouré de « plus » et de « que » il ne fait aucun doute pour moi qu’il s’agit d’un adjectif…

Traduisons cette question par :
« de manière générale, XFCE est-il moins capricieux que GNOME en sid ? »
C’est bon, « capricieux » n’est pas nom de dépôt :wink: Pour faire plus dans le détail, je m’en suis expliqué au 5ème post.

Comme il a été ajouté :

#15

Xfce étant plus léger que gnome, il va de soit qu’il sera proportionnellement moins buggé :unamused: Si tu trouves des statistiques, je serais curieux d’en prendre connaissance.

#16

Salut,

Toujours est-il que, KDE ne me pose guère de souci, lui !

#17

Mon idée aussi est que XFCE est plus modulaire, moins intégré, et c’est ça qui fait la différence en terme de sac de nœuds et de cloisonnement des bugs :

« Afin de réaliser ces objectifs, Xfce est fidèle à la philosophie traditionnelle de modularité et de réutilisabilité d’UNIX. Il est constitué de plusieurs composants qui, assemblés, fournissent toutes les fonctionnalités d’un environnement de bureau. Ces composants sont disponibles séparément, ce qui permet à l’utilisateur de sélectionner ceux dont il a besoin afin de créer l’environnement de travail le plus adapté. Il en va de même pour les applications associées à Xfce.» – source

Vous connaissez ça ? http://edos.debian.net/weather/

Avec l’historique du suivi des données de bugs par paquet, pour se faire une idée. Quelque chose me dit qu’avec un peu de data-mining ce serait possible, http://www.debian.org/Bugs/Access. Il y a moyen d’accéder aux archives, ce qui fait quand même plus de 10Go de données. Quant à la catégorisation des paquets… je ne saurais comment m’y prendre.

#18

apt-listbugs est là, tout naturellement pour y pallier.

#19

Dans la maintenance au quotidien apt-listbugs est pas mal, certes. Il faudrait que j’apprenne à le manier, ou plutôt à manier aptitude de concert avec apt-listbugs… (j’ai eu quelques mésaventures en utilisant le - sans vérifier les modifications avant installer/enlever les paquets :blush:).

Ce qui intéressait svOt (et moi), ce sont des statistiques sur les bugs par projets d’environnement de bureau. Comme je disais, un critère intéressant serait le nombre de bugs qui se faufilent en testing. Après il y a bug et bug, si on ne s’intéresse qu’aux gros bugs il faut compter sur la classification qui dépend de celui qui remplit le bug et des usages qui varient sans doute en fonction du projet (ce que je vois dans l’utilisation de bugzilla au travail).

#20

[quote=“bobo38”]Dans la maintenance au quotidien apt-listbugs est pas mal, certes. Il faudrait que j’apprenne à le manier, ou plutôt à manier aptitude de concert avec apt-listbugs… (j’ai eu quelques mésaventures en utilisant le - sans vérifier les modifications avant installer/enlever les paquets :blush:).

Ce qui intéressait svOt (et moi), ce sont des statistiques sur les bugs par projets d’environnement de bureau. Comme je disais, un critère intéressant serait le nombre de bugs qui se faufilent en testing. Après il y a bug et bug, si on ne s’intéresse qu’aux gros bugs il faut compter sur la classification qui dépend de celui qui remplit le bug et des usages qui varient sans doute en fonction du projet (ce que je vois dans l’utilisation de bugzilla au travail).[/quote]

Ce que je ne comprends pas c’est qu’en utilisant apt-listbugs ( en gros juste ne l’installant :whistle: ) il vérifie la présence de beug déclaré sur les paquets qui vont être mis à jour.

Il n’y a qu’à lire ce qu’il déclare et analyser patiemment si le beug nous concerne et si il est véritablement bloquant, dans ce cas il suffit de marquer le paquet en hold :033

Pour ce qui est de aptitude, son grand + c’est de pouvoir proposer assez simplement une ou des solutions alternatives selonj le fichier de sources tout en prenant compte le fichier de préférences d’adapter la mise à jour du système.