Me fait pas dire ce que je n'ai pas dit. J'ai dit que d'autres projets mériteraient davantage (remarque l'emploi du conditionnel), c'est pas pour autant que je trouve qu'ils méritent un journal ou une couverture médiatique eux aussi parce que même s'ils sont plus complexes ils n'ont pas beaucoup plus d'intérêt que celui présenté ici.
Le pire avec les sucres s'était les câbles de port USB, beaucoup trop petits pour les vis.
C'est classique : le fil passe sur le côté de la vis en serrant.
remplacer la boite plastique par un équivalent métal.
Tu peux récupérer une petite tour pour microATX que tu pose horizontalement, les ventilateurs auront leurs attaches et avec un peu de découpe tu peux te servir des emplacements 3.5" pour mettre tes SBC à l'avant.
Pour loger deux SBC, un HDD 2.5" et un ventilo 80mm j'ai réutilisé le boitier d'une alim ATX.
soit en trouvant comment contrôler les ventilos de recup de la même façon qu'une tour contrôle son ventilo de CPU, soit en utilisant un RPI + relais)
Vu qu'il n'y a souvent pas de sonde de température sur ces cartes, il va falloir en ajouter un peu partout. Le RPi n'a pas d'entrée analogique donc ce serait des modules en SPI ou I²C sinon prévois un microcontroleur pour les sonde analogiques. Il y a aussi moyen de monitorer la rotation sur les ventilateurs disposant d'un troisième fil.
Après pour avoir plus de deux paliers de vitesse de rotation (comme sur une tour), tu peux utiliser un petit convertisseur de tension DC/DC et si tes ventilateurs ne supportent pas le PWM en interne (pas de quatrième broche) mais que tu veux tout de même le faire il vaudra mieux un mosfet qu'un relai pour générer le duty cycle.
Tu trouveras des schémas, des tutos voire même des kits et des modules tout fait (par exemple ce tout-en-un).
comme dit précédemment, si on en parle c'est à cause de sa campagne marketing. Il y a plein d'autres projets OSHW qui mériteraient beaucoup plus cette attention. Suffit de chercher sur les sites de DIY.
Ce journal sur Linuxfr n'est que le résultat de cette campagne.
En plus la boite ne vend que le système assemblé, pas les pièces pour ceux qui voudraient n'acheter que leurs boitiers, et ne met pas en avant les plans (Le dépôt github n'est même pas trouvable depuis leur site web, un comble).
J'ai bien lu, mais je désapprouve l'intérêt porté sur cette initiative. Ça n'est pas plus intéressant que la tonne de projets listés sur des sites de DIY/Maker et compagnie, il n'y a rien de compliqué ou d'innovant qui mériterait autant d'attention. L'étape n'existe pas quand c'est une fonctionnalité en doublon avec la carte-mère et que des fabricants comme Olimex, Purism ou Raptor Engineering proposent des choses bien plus chiadées. Cette carte c'est le genre de truc qui fini en kits d'initiation sur des sites chinois du genre AliExpress ou Banggood.
Si on en parle c'est uniquement à cause de sa campagne marketing basé sur les expressions "open-hardware" et "made in USA" plutôt fumeuses et le design tendance/chic/rétro du boitier bois+alu (DIYPerks a conçu des boitiers dans le même genre de matériaux avec des formes plus décoratives et on trouve un bon paquet de gens qui font ce genre de casemod) D'ailleurs la plupart des avis que j'ai lu sous les articles concernant ce produit sont aussi dubitatifs que le mien.
Pas grand chose de libre ici (des cartes mères Gigabyte avec un BIOS AMI et des CPU AMD/Intel) à part le design des boitiers et la petite carte IO. Les specs de la carte Thelio IO n'ont absolument rien d’impressionnant, c'est un bête atmega32u4 qui gère les ventilateurs et les sondes. La partie SATA ou SAS n'est qu'un berceau destiné à une utilisation de type rack.
ÀMHA, beaucoup de bruit pour rien. Mais bon leur campagne marketing a le mérite de faire vivre des webdesigners et des graphistes.
Ce que tu peux faire c'est uniquement mettre uboot ou bootcode.bin sur une carte SD (ou une EEPROM en SPI/I²C ou sur la puce NAND/eMMC présente sur la carte : possible pour tes XU4) et lancer le noyau depuis un SSD branché en USB ou disponible via le réseau.
J'apprécie surtout leur très faible consommation, particulièrement en idle, comparé aux tours de récup. (la boite n'a pour le moment jamais dépassé les 48W)
Je crois que tu n'as pas compris la comparaison et que tu as confondu avec le terme devboard :)
Une breadboard (ou platine d'expérimentation) c'est le genre de support de prototypage de circuits électroniques utilisé notamment avec des microcontroleurs. C'est rapide d'y brancher les composants et de faire des modifications du circuit mais les connexions sont de mauvaise qualité (aussi il y a beaucoup de bruit électronique qui peut nuire aux fonctionnements à haute fréquence). C'est la même chose avec des sucres ou autres connexions avec une simple vis.
Le refroidissement à droit à une double prise
Du coup tu gères comment la commutation entre les deux tensions ? Tu as des sondes et un controleur quelque part pour automatiser ça ?
Pour plus d'efficacité de refroidissement, tu peux aussi ajouter un ventilateur d'extraction à l'arrière comme dans un boitier ATX.
Ah des XU4. Avec toutes les cartes existantes c'est parfois difficile à reconnaitre. Ça fait une sacrée upgrade à moins qu'elles soient aussi utilisées pour autre chose.
Sinon je parlais des deux connecteurs blancs en bas à gauche près des ventilateurs et au milieu, c'est bien ce que tu appelles des sucres ? Désolé le jargon est différent selon de quel côté de la frontière on se situe ' C'est comme utiliser une breadboard : c'est bien pour tester mais vaut mieux passer à du plus costaud quand on pérénise un montage. Ce genre de connecteur c'est acceptable pour du circuit électrique d'habitation à des tensions relativement élevées (peu de pertes ohmiques) et avec des fils monobrins (qui vont garder l'empreinte de la vis même si elle se déssert un poil), pour le reste il vaut mieux éviter.
Pour les ports USB, certains modèles de SBC dont les RPi sont réputés plus stables quand on utilise les broches GPIO +5V et GND à la place du miniUSB qui, contrairement à un véritable connecteur d'alimentation du type barrel plug (utilisé sur Olinuxino, Cubieboard ou tes Odroid), peut causer des microcoupures ainsi que des pertes ohmiques. Donc tu pourrais éventuellement faire ce changement ce qui te permettrait aussi de virer le powerhub usb en haut à droite et de tout repiquer sur l'alim 5V 50A utilisée pour les autres cartes (et les ventilateurs je suppose). Si elle est pas trop pourrie, l'alim n'est pas à 3 ou 4A près. Même dans le pire scénario, avec toutes tes cartes en burn, elle ne sera qu'à un maximum de 80% de sa charge max.
C'est dommage, je vois pas ce que tu a utilisé comme SBC pour ton cluster. Toujours du ARM ? En tout cas ça ressemble pas à du RPi, même sans le joli radiateur.
Enfin, fais gaffe avec les dominos. C'est pas très fiable que ce soit niveau contacts ou niveau fixation. Utilise plutôt des connecteurs à souder ou à sertir, ça coûte pas grand chose et ça peut éviter des catastrophes.
Certaines libs sont disponibles en backports et d'autres non, ca pourrait venir d'ici ?
En partie oui. backports a une priorité basse par rapport aux dépôts stable donc la résolution ne fonctionne pas bien quand il y a plusieurs paquets backports à installer ou mettre à jour automatiquement. Avec un paquet simple en dépendance, le gestionnaire de paquets trouve facilement et propose l'installation des nouveaux paquets backports. Ici tu as plusieurs paquets avec de multiples dépendances profondes à résoudre, c'est trop compliqué pour le gestionnaire.
Remarque bien que là sur tes screenshots ce ne sont pas les dépendances elles-mêmes qui bloquent (si tu regardes le numéro de version des dépendances disponibles, il est bien supérieur ou égal à celui exigé par le paquet) mais ce sont des paquets encore en-dessous. En descendant plus profond tu vas trouver les coupables.
J'ai beau tenter et chercher partout, backports ou pas, à chaque fois un conflit 32/64 bits…
Oui tu arrives à des paquets avec des conflits non pas dans la partie Dépend mais dans la partie Casse, probablement en 64bits et restés en stable. C'est une partie de la difficulté de l'opération qui contribue à mettre en défaut la résolution automatique. Les lib graphiques en multiarch doivent être de même version. C'est pour ça que j'insiste sur les paquets 64bits. :)
Tente de simuler l'installation d'un de ces paquets avec aptitude, regarde à chaque manipulation ce qu'il propose comme solutions de résolution (parfois il faut faire suivant jusque sa quatrième ou cinquième solution pour avoir quelque chose qui convient), regarde ce qu'il indique comme conflits et creuse jusqu'à ce qu'un paquet propose la bonne solution de résolution. C'est comme ça que j'ai fait pour libdrm2:i386
Il y a de fortes chances qu'il faille faire ça à plusieurs endroits mais tu vas aussi avoir des sous-dépendances communes qui débloquent plusieurs paquets supérieurs. Et comme tu l'as supposé, ça va fortement aider à résoudre ton problème similaire avec Wine.
C'est un travail de détective. Avec l'habitude de l'outil, tu finiras par régler ce genre de problème en quelques minutes. Surtout qu'après avoir résolu des grosses lib graphiques, toi et le gestionnaire auront beaucoup moins de conflits à résoudre, jusqu'à la prochaine dist-upgrade.
Il faut vérifier la licence pour chaque cas, mais quand tu as le SVG disponible, il suffit de regarder dans le fichier pour savoir ce que tu peux ou ne peux pas faire.
libdrm2 64bits était bien installée, c'était la version 32 bits qui coincait, mais pour une raison inconnue, après une mise à jour, un simple sudo apt install -t stretch-backports libdrm2:i386 a eu raison de lui.
"Après une mise à jour" ça veut dire quoi ? apt-get upgrade ou update ? Et ça a mis à jour quels paquets ?
J'ai pas tout essayé en 64 bits mais a chaque essai, la lib était bien installée en 64 bits.
En version backports ? et quelle version de Steam : stable, backports ou celle du dépot tiers de Valve ? parce que le schéma que tu montres c'est typiquement ce qu'il se passe avec une dépendance backports qui veut pas se mettre à jour.
Un paquet comme libdrm-amdgpu1:i386 ne dépend que de libdrm2:i386 donc maintenant tu devrais pouvoir l'installer en backports si tu as bien le paquet amdgpu1 64bits qui est installé en backports.
Le support du multi-arch n'a pas de soucis particuliers, c'est plutôt backports qui pose généralement des problèmes de résolution de conflits même sans multi-arch (et pour preuve : rien qu'installer les paquets backports 64bits rend fou le gestionnaire de paquets).
Continue de creuser les dépendances et conflits, je suis certain que tu retomberas à peu près sur la liste que j'avais eu avec aptitude (et franchement c'est bien plus simple à gérer avec le TUI ou un bon GUI). Après je n'ai pas KDE donc ça pourrait aussi ajouter des conflits supplémentaires.
Et cette ligne dans shadow dit tout simplement que l'utilisateur root n'a pas de mot de passe. Il suffit de faire su ou sudo pour passer en root sans mot de passe !
Pas du tout :
# grep root /etc/shadow
root::17409:0:99999:7:::
# exit
$ su -
Mot de passe :
su : Échec d'authentification
$ su - root
Mot de passe :
su : Échec d'authentification
$ su
Mot de passe :
su : Échec d'authentification
Par contre sur la console, il suffit de taper root dans le champ login pour se connecter.
c'est apt-get , pas apt ;)
Pas de problème pour le délai, par contre ici tu ne me donnes pas plus d'infos pour continuer à t'aider donc tout ce que je peux dire c'est qu'il faut que tu persistes à chercher pourquoi libdrm2 64bits en version backports ne veut pas s'installer sur ta Debian.
Quand on lit l'annonce d'IBM, on peut constater que RedHat restera une entité à part de BigBlue :
Upon closing of the acquisition, Red Hat will join IBM's Hybrid Cloud team as a distinct unit, preserving the independence and neutrality of Red Hat's open source development heritage and commitment, current product portfolio and go-to-market strategy, and unique development culture. Red Hat will continue to be led by Jim Whitehurst and Red Hat's current management team. Jim Whitehurst also will join IBM's senior management team and report to Ginni Rometty. IBM intends to maintain Red Hat's headquarters, facilities, brands and practices.
Je ne comprends pas pourquoi tu tires ce genre de conclusion, il faut que tu expliques en quoi IBM qui joue pleinement le jeu de l'opensource depuis OpenPower va tuer le Linux en entreprise.
OK, du coup le truc qui bloque c'est que en 64bits tes libs mesa, drm et wayland sont toujours en version stable, il faut les upgrader en backports pour que ça passe.
Je viens de tester chez moi et ce n'est pas trivial, aptitude a bien du mal parce que effectivement c'est pas la seule lib à casser, mais à force d'insister manuellement ça fonctionne.
Paquets à mettre à jour :
libdrm-amdgpu1 libdrm-nouveau2 libdrm-intel1 libdrm-radeon1 libdrm2 libegl1-mesa libgbm1 libgl1-mesa-dri libwayland-client0 libwayland-server0
Non mon gars, ou alors tu estimes très faiblement la population qui rédige avec un clavier physique de manière quotidienne. L'utilité arrive d'ailleurs assez tôt dans la scolarité, rien que pour faire un compte-rendu de stage, une rédaction, écrire un courriel ou une lettre de motivation. Puis de nos jours au moins un tiers des jobs se font en partie assis derrière un clavier à saisir du texte.
Enfin niveau posture, devoir perpétuellement faire l'aller-retour entre l'écran et le clavier se termine en inconfort, douleurs et ralentissement de la saisie.
Oui la TUI est spéciale mais pratique pour avoir une vue d'ensemble et le détail de chaque versions de paquets disponibles via les dépots.
Sinon avec l'option -t de apt-get, est-ce qu'installer la version de steam présente dans stable pose problème ? même question pour la version backports.
à chaque fois je retombe sur un conflit d'une lib qui ne peut être en 32 bits et en 64 bits à la fois
Quelles lib ? version stable ou backports ?
Le conflit entre les lib 32 et 64 peut arriver parce que aptitude cherche à installer la version stable de la 32 bits alors que tu as la version backports de la 64 ou vice versa.
Après ça peut arriver d'avoir des paquets mal fichus vu que backports est un court-circuit de testing/sid. Je me souviens d'avoir laché l'affaire sur le paquet backports de VLC.
On va regarder avec une dépendance qui ne dépend pas de backports :
Donne moi la sortie de la commande sudo apt-get install zlib1g:i386
puis si ça veut pas s'installer, même chose avec libc6:i386
puis libgcc1:i386
puis ces deux dernières dans la même commande
De ce que je vois il y a une boucle de dépendance entre ces deux libs, ça pourrait éventuellement mettre le souk dans la résolution de apt et aptitude. Vu que ce sont des libs indispensables à beaucoup de programmes ça pourrait tout résoudre d'un coup.
Si elles ne veulent pas s'installer, il va falloir forcer leur installation.
Ce qu'on peut faire aussi (que ce soit à l'école ou à la maison) c'est leur enseigner la saisie dactylographique. Certes avec les écrans tactiles ce n'est pas pertinent mais pour tout travail de rédaction (scolaire ou professionnel) le clavier à touches physiques garde son utilité.
Après ce n'est pas nécessairement quelque chose de pertinent pour les élèves de primaire mais ça devient assez essentiel par la suite.
j'adorais les pommes, pratique, resiste au choc etc … bref
un jour en croquant dans une pomme, une partie de la peau de la pomme c'est glissé entre ma gencive et mes dents, longue histoire medical plus tard chez le dentiste … sans anesthesie.
En plus de VLC (que j'utilise principalement pour regarder des rediffusion de Twitch sans inscription ni le chat) et de Newpipe sur Android, il manque le programme minitube mais celui-ci requiert une clé pour GoogleAPI qui n'est pas toujours fournie par les distributions.
Dans ce cas, aptitude ne me proposerait-il pas de retrograder les paquets en question ? Car là il ne le fait pas.
J'utilise aptitude en interface ncurses depuis des années et son système de résolution de conflits est parfois tordu, surtout quand ça implique backports. Il m'arrive régulièrement de devoir fouiller dans l'arbre de dépendance et d'installer manuellement un ou deux paquets pour arriver à mes fins parce qu'aucune des solutions trouvées par aptitude ne le fait.
En ligne de commande c'est encore pire vu que bien souvent aptitude ne propose que sa première suggestion qui, quand ça bloque, se résume à ne pas installer les nouveaux paquets ou à remplacer la moitié de ceux installés.
Pour ton problème, tente de voir si tu arrives à quelque chose avec le TUI d'aptitude en simulant les installations manuelles des paquets que j'ai cité à la fin de mon message précédent. Cherche jusqu'à ce qu'il n'y ait plus de message d'erreur. Tu peux revenir en arrière dans le menu Action (Ctrl+t) > Annuler les actions en attente (raccourci en touche l)
[^] # Re: open-washing
Posté par Anonyme . En réponse au journal Thelio Io, de l'Open-Hardware par System76. Évalué à 0.
Me fait pas dire ce que je n'ai pas dit. J'ai dit que d'autres projets mériteraient davantage (remarque l'emploi du conditionnel), c'est pas pour autant que je trouve qu'ils méritent un journal ou une couverture médiatique eux aussi parce que même s'ils sont plus complexes ils n'ont pas beaucoup plus d'intérêt que celui présenté ici.
[^] # Re: Nouvelle maison
Posté par Anonyme . En réponse au journal Le roi est mort, Vive le roi !. Évalué à 2.
C'est classique : le fil passe sur le côté de la vis en serrant.
Tu peux récupérer une petite tour pour microATX que tu pose horizontalement, les ventilateurs auront leurs attaches et avec un peu de découpe tu peux te servir des emplacements 3.5" pour mettre tes SBC à l'avant.
Pour loger deux SBC, un HDD 2.5" et un ventilo 80mm j'ai réutilisé le boitier d'une alim ATX.
Vu qu'il n'y a souvent pas de sonde de température sur ces cartes, il va falloir en ajouter un peu partout. Le RPi n'a pas d'entrée analogique donc ce serait des modules en SPI ou I²C sinon prévois un microcontroleur pour les sonde analogiques. Il y a aussi moyen de monitorer la rotation sur les ventilateurs disposant d'un troisième fil.
Après pour avoir plus de deux paliers de vitesse de rotation (comme sur une tour), tu peux utiliser un petit convertisseur de tension DC/DC et si tes ventilateurs ne supportent pas le PWM en interne (pas de quatrième broche) mais que tu veux tout de même le faire il vaudra mieux un mosfet qu'un relai pour générer le duty cycle.
Tu trouveras des schémas, des tutos voire même des kits et des modules tout fait (par exemple ce tout-en-un).
[^] # Re: open-washing
Posté par Anonyme . En réponse au journal Thelio Io, de l'Open-Hardware par System76. Évalué à 0. Dernière modification le 05 novembre 2018 à 00:59.
comme dit précédemment, si on en parle c'est à cause de sa campagne marketing. Il y a plein d'autres projets OSHW qui mériteraient beaucoup plus cette attention. Suffit de chercher sur les sites de DIY.
Ce journal sur Linuxfr n'est que le résultat de cette campagne.
En plus la boite ne vend que le système assemblé, pas les pièces pour ceux qui voudraient n'acheter que leurs boitiers, et ne met pas en avant les plans (Le dépôt github n'est même pas trouvable depuis leur site web, un comble).
[^] # Re: open-washing
Posté par Anonyme . En réponse au journal Thelio Io, de l'Open-Hardware par System76. Évalué à 9. Dernière modification le 04 novembre 2018 à 13:42.
J'ai bien lu, mais je désapprouve l'intérêt porté sur cette initiative. Ça n'est pas plus intéressant que la tonne de projets listés sur des sites de DIY/Maker et compagnie, il n'y a rien de compliqué ou d'innovant qui mériterait autant d'attention. L'étape n'existe pas quand c'est une fonctionnalité en doublon avec la carte-mère et que des fabricants comme Olimex, Purism ou Raptor Engineering proposent des choses bien plus chiadées. Cette carte c'est le genre de truc qui fini en kits d'initiation sur des sites chinois du genre AliExpress ou Banggood.
Si on en parle c'est uniquement à cause de sa campagne marketing basé sur les expressions "open-hardware" et "made in USA" plutôt fumeuses et le design tendance/chic/rétro du boitier bois+alu (DIYPerks a conçu des boitiers dans le même genre de matériaux avec des formes plus décoratives et on trouve un bon paquet de gens qui font ce genre de casemod) D'ailleurs la plupart des avis que j'ai lu sous les articles concernant ce produit sont aussi dubitatifs que le mien.
# open-washing
Posté par Anonyme . En réponse au journal Thelio Io, de l'Open-Hardware par System76. Évalué à 7.
Pas grand chose de libre ici (des cartes mères Gigabyte avec un BIOS AMI et des CPU AMD/Intel) à part le design des boitiers et la petite carte IO.
Les specs de la carte Thelio IO n'ont absolument rien d’impressionnant, c'est un bête atmega32u4 qui gère les ventilateurs et les sondes. La partie SATA ou SAS n'est qu'un berceau destiné à une utilisation de type rack.
ÀMHA, beaucoup de bruit pour rien. Mais bon leur campagne marketing a le mérite de faire vivre des webdesigners et des graphistes.
[^] # Re: Vous l'avez quand même cherché
Posté par Anonyme . En réponse au journal Le roi est mort, Vive le roi !. Évalué à 1. Dernière modification le 04 novembre 2018 à 05:35.
Ce que tu peux faire c'est uniquement mettre uboot ou bootcode.bin sur une carte SD (ou une EEPROM en SPI/I²C ou sur la puce NAND/eMMC présente sur la carte : possible pour tes XU4) et lancer le noyau depuis un SSD branché en USB ou disponible via le réseau.
[^] # Re: Nouvelle maison
Posté par Anonyme . En réponse au journal Le roi est mort, Vive le roi !. Évalué à 2.
Je crois que tu n'as pas compris la comparaison et que tu as confondu avec le terme devboard :)
Une breadboard (ou platine d'expérimentation) c'est le genre de support de prototypage de circuits électroniques utilisé notamment avec des microcontroleurs. C'est rapide d'y brancher les composants et de faire des modifications du circuit mais les connexions sont de mauvaise qualité (aussi il y a beaucoup de bruit électronique qui peut nuire aux fonctionnements à haute fréquence). C'est la même chose avec des sucres ou autres connexions avec une simple vis.
Du coup tu gères comment la commutation entre les deux tensions ? Tu as des sondes et un controleur quelque part pour automatiser ça ?
Pour plus d'efficacité de refroidissement, tu peux aussi ajouter un ventilateur d'extraction à l'arrière comme dans un boitier ATX.
[^] # Re: Nouvelle maison
Posté par Anonyme . En réponse au journal Le roi est mort, Vive le roi !. Évalué à 2. Dernière modification le 03 novembre 2018 à 01:21.
Ah des XU4. Avec toutes les cartes existantes c'est parfois difficile à reconnaitre. Ça fait une sacrée upgrade à moins qu'elles soient aussi utilisées pour autre chose.
Sinon je parlais des deux connecteurs blancs en bas à gauche près des ventilateurs et au milieu, c'est bien ce que tu appelles des sucres ? Désolé le jargon est différent selon de quel côté de la frontière on se situe ' C'est comme utiliser une breadboard : c'est bien pour tester mais vaut mieux passer à du plus costaud quand on pérénise un montage. Ce genre de connecteur c'est acceptable pour du circuit électrique d'habitation à des tensions relativement élevées (peu de pertes ohmiques) et avec des fils monobrins (qui vont garder l'empreinte de la vis même si elle se déssert un poil), pour le reste il vaut mieux éviter.
Pour les ports USB, certains modèles de SBC dont les RPi sont réputés plus stables quand on utilise les broches GPIO +5V et GND à la place du miniUSB qui, contrairement à un véritable connecteur d'alimentation du type barrel plug (utilisé sur Olinuxino, Cubieboard ou tes Odroid), peut causer des microcoupures ainsi que des pertes ohmiques. Donc tu pourrais éventuellement faire ce changement ce qui te permettrait aussi de virer le powerhub usb en haut à droite et de tout repiquer sur l'alim 5V 50A utilisée pour les autres cartes (et les ventilateurs je suppose). Si elle est pas trop pourrie, l'alim n'est pas à 3 ou 4A près. Même dans le pire scénario, avec toutes tes cartes en burn, elle ne sera qu'à un maximum de 80% de sa charge max.
# Nouvelle maison
Posté par Anonyme . En réponse au journal Le roi est mort, Vive le roi !. Évalué à 4.
C'est dommage, je vois pas ce que tu a utilisé comme SBC pour ton cluster. Toujours du ARM ? En tout cas ça ressemble pas à du RPi, même sans le joli radiateur.
Enfin, fais gaffe avec les dominos. C'est pas très fiable que ce soit niveau contacts ou niveau fixation. Utilise plutôt des connecteurs à souder ou à sertir, ça coûte pas grand chose et ça peut éviter des catastrophes.
[^] # Re: sans titre
Posté par Anonyme . En réponse au message Mise à jour/Installation Steam Debian Conflit de paquets. Évalué à 1.
En partie oui. backports a une priorité basse par rapport aux dépôts stable donc la résolution ne fonctionne pas bien quand il y a plusieurs paquets backports à installer ou mettre à jour automatiquement. Avec un paquet simple en dépendance, le gestionnaire de paquets trouve facilement et propose l'installation des nouveaux paquets backports. Ici tu as plusieurs paquets avec de multiples dépendances profondes à résoudre, c'est trop compliqué pour le gestionnaire.
Remarque bien que là sur tes screenshots ce ne sont pas les dépendances elles-mêmes qui bloquent (si tu regardes le numéro de version des dépendances disponibles, il est bien supérieur ou égal à celui exigé par le paquet) mais ce sont des paquets encore en-dessous. En descendant plus profond tu vas trouver les coupables.
Oui tu arrives à des paquets avec des conflits non pas dans la partie Dépend mais dans la partie Casse, probablement en 64bits et restés en stable. C'est une partie de la difficulté de l'opération qui contribue à mettre en défaut la résolution automatique. Les lib graphiques en multiarch doivent être de même version. C'est pour ça que j'insiste sur les paquets 64bits. :)
Tente de simuler l'installation d'un de ces paquets avec aptitude, regarde à chaque manipulation ce qu'il propose comme solutions de résolution (parfois il faut faire suivant jusque sa quatrième ou cinquième solution pour avoir quelque chose qui convient), regarde ce qu'il indique comme conflits et creuse jusqu'à ce qu'un paquet propose la bonne solution de résolution. C'est comme ça que j'ai fait pour libdrm2:i386
Il y a de fortes chances qu'il faille faire ça à plusieurs endroits mais tu vas aussi avoir des sous-dépendances communes qui débloquent plusieurs paquets supérieurs. Et comme tu l'as supposé, ça va fortement aider à résoudre ton problème similaire avec Wine.
C'est un travail de détective. Avec l'habitude de l'outil, tu finiras par régler ce genre de problème en quelques minutes. Surtout qu'après avoir résolu des grosses lib graphiques, toi et le gestionnaire auront beaucoup moins de conflits à résoudre, jusqu'à la prochaine dist-upgrade.
# A ma connaissance…
Posté par Anonyme . En réponse au message Logo de Linuxfr.org ?. Évalué à 6.
… tout est là: https://linuxfr.org/images/logos/
Il faut vérifier la licence pour chaque cas, mais quand tu as le SVG disponible, il suffit de regarder dans le fichier pour savoir ce que tu peux ou ne peux pas faire.
[^] # Re: sans titre
Posté par Anonyme . En réponse au message Mise à jour/Installation Steam Debian Conflit de paquets. Évalué à 1.
"Après une mise à jour" ça veut dire quoi ? apt-get upgrade ou update ? Et ça a mis à jour quels paquets ?
En version backports ? et quelle version de Steam : stable, backports ou celle du dépot tiers de Valve ? parce que le schéma que tu montres c'est typiquement ce qu'il se passe avec une dépendance backports qui veut pas se mettre à jour.
Un paquet comme libdrm-amdgpu1:i386 ne dépend que de libdrm2:i386 donc maintenant tu devrais pouvoir l'installer en backports si tu as bien le paquet amdgpu1 64bits qui est installé en backports.
Le support du multi-arch n'a pas de soucis particuliers, c'est plutôt backports qui pose généralement des problèmes de résolution de conflits même sans multi-arch (et pour preuve : rien qu'installer les paquets backports 64bits rend fou le gestionnaire de paquets).
Continue de creuser les dépendances et conflits, je suis certain que tu retomberas à peu près sur la liste que j'avais eu avec aptitude (et franchement c'est bien plus simple à gérer avec le TUI ou un bon GUI). Après je n'ai pas KDE donc ça pourrait aussi ajouter des conflits supplémentaires.
[^] # Re: Magnifique !
Posté par Anonyme . En réponse au journal La faille grosse comme une maison. Évalué à 4. Dernière modification le 29 octobre 2018 à 20:48.
Pas du tout :
Par contre sur la console, il suffit de taper
rootdans le champ login pour se connecter.[^] # Re: sans titre
Posté par Anonyme . En réponse au message Mise à jour/Installation Steam Debian Conflit de paquets. Évalué à 1.
c'est apt-get , pas apt ;)
Pas de problème pour le délai, par contre ici tu ne me donnes pas plus d'infos pour continuer à t'aider donc tout ce que je peux dire c'est qu'il faut que tu persistes à chercher pourquoi libdrm2 64bits en version backports ne veut pas s'installer sur ta Debian.
[^] # Re: Microsoft en rêvait
Posté par Anonyme . En réponse au journal IBM achète Red Hat. Évalué à 6.
Quand on lit l'annonce d'IBM, on peut constater que RedHat restera une entité à part de BigBlue :
[^] # Re: Microsoft en rêvait
Posté par Anonyme . En réponse au journal IBM achète Red Hat. Évalué à 9.
Je ne comprends pas pourquoi tu tires ce genre de conclusion, il faut que tu expliques en quoi IBM qui joue pleinement le jeu de l'opensource depuis OpenPower va tuer le Linux en entreprise.
[^] # Re: sans titre
Posté par Anonyme . En réponse au message Mise à jour/Installation Steam Debian Conflit de paquets. Évalué à 1.
OK, du coup le truc qui bloque c'est que en 64bits tes libs mesa, drm et wayland sont toujours en version stable, il faut les upgrader en backports pour que ça passe.
Je viens de tester chez moi et ce n'est pas trivial, aptitude a bien du mal parce que effectivement c'est pas la seule lib à casser, mais à force d'insister manuellement ça fonctionne.
Paquets à mettre à jour :
libdrm-amdgpu1 libdrm-nouveau2 libdrm-intel1 libdrm-radeon1 libdrm2 libegl1-mesa libgbm1 libgl1-mesa-dri libwayland-client0 libwayland-server0
[^] # Re: Patatras !
Posté par Anonyme . En réponse à la dépêche LibreOffice : nouvelle version de l’interface des écoles. Évalué à 5.
Non mon gars, ou alors tu estimes très faiblement la population qui rédige avec un clavier physique de manière quotidienne. L'utilité arrive d'ailleurs assez tôt dans la scolarité, rien que pour faire un compte-rendu de stage, une rédaction, écrire un courriel ou une lettre de motivation. Puis de nos jours au moins un tiers des jobs se font en partie assis derrière un clavier à saisir du texte.
Enfin niveau posture, devoir perpétuellement faire l'aller-retour entre l'écran et le clavier se termine en inconfort, douleurs et ralentissement de la saisie.
[^] # Re: sans titre
Posté par Anonyme . En réponse au message Mise à jour/Installation Steam Debian Conflit de paquets. Évalué à 1.
Oui la TUI est spéciale mais pratique pour avoir une vue d'ensemble et le détail de chaque versions de paquets disponibles via les dépots.
Sinon avec l'option -t de apt-get, est-ce qu'installer la version de steam présente dans stable pose problème ? même question pour la version backports.
Quelles lib ? version stable ou backports ?
Le conflit entre les lib 32 et 64 peut arriver parce que aptitude cherche à installer la version stable de la 32 bits alors que tu as la version backports de la 64 ou vice versa.
Après ça peut arriver d'avoir des paquets mal fichus vu que backports est un court-circuit de testing/sid. Je me souviens d'avoir laché l'affaire sur le paquet backports de VLC.
On va regarder avec une dépendance qui ne dépend pas de backports :
Donne moi la sortie de la commande sudo apt-get install zlib1g:i386
puis si ça veut pas s'installer, même chose avec libc6:i386
puis libgcc1:i386
puis ces deux dernières dans la même commande
De ce que je vois il y a une boucle de dépendance entre ces deux libs, ça pourrait éventuellement mettre le souk dans la résolution de apt et aptitude. Vu que ce sont des libs indispensables à beaucoup de programmes ça pourrait tout résoudre d'un coup.
Si elles ne veulent pas s'installer, il va falloir forcer leur installation.
[^] # Re: Patatras !
Posté par Anonyme . En réponse à la dépêche LibreOffice : nouvelle version de l’interface des écoles. Évalué à 1.
Ce qu'on peut faire aussi (que ce soit à l'école ou à la maison) c'est leur enseigner la saisie dactylographique. Certes avec les écrans tactiles ce n'est pas pertinent mais pour tout travail de rédaction (scolaire ou professionnel) le clavier à touches physiques garde son utilité.
Après ce n'est pas nécessairement quelque chose de pertinent pour les élèves de primaire mais ça devient assez essentiel par la suite.
[^] # Re: Mangez des pommes.
Posté par Anonyme . En réponse au journal La compote de pommes en gourde n'est PAS un truc de fainéant.. Évalué à 2.
j'adorais les pommes, pratique, resiste au choc etc … bref
un jour en croquant dans une pomme, une partie de la peau de la pomme c'est glissé entre ma gencive et mes dents, longue histoire medical plus tard chez le dentiste … sans anesthesie.
depuis je les épluches mais c'est moins pratique
[^] # Re: facile de repondre a ta question
Posté par Anonyme . En réponse au journal Est-ce qu'on est sérieux?. Évalué à 6.
bien avoir un KDE
"up-to-date".qui risque de se casser sans prevenirde rien
[^] # Re: Tout d'horizon
Posté par Anonyme . En réponse au journal Voir les vidéos YouTube en ligne sans être vu de Google. Évalué à 1.
En plus de VLC (que j'utilise principalement pour regarder des rediffusion de Twitch sans inscription ni le chat) et de Newpipe sur Android, il manque le programme minitube mais celui-ci requiert une clé pour GoogleAPI qui n'est pas toujours fournie par les distributions.
[^] # Re: Forcer la main, ou juste respecter les (anciennes) règles?
Posté par Anonyme . En réponse au journal SSPL: All your service are belong to us. Évalué à 3.
Oui, mais là on parle de M o ngoDB.
[^] # Re: sans titre
Posté par Anonyme . En réponse au message Mise à jour/Installation Steam Debian Conflit de paquets. Évalué à 1. Dernière modification le 23 octobre 2018 à 19:25.
J'utilise aptitude en interface ncurses depuis des années et son système de résolution de conflits est parfois tordu, surtout quand ça implique backports. Il m'arrive régulièrement de devoir fouiller dans l'arbre de dépendance et d'installer manuellement un ou deux paquets pour arriver à mes fins parce qu'aucune des solutions trouvées par aptitude ne le fait.
En ligne de commande c'est encore pire vu que bien souvent aptitude ne propose que sa première suggestion qui, quand ça bloque, se résume à ne pas installer les nouveaux paquets ou à remplacer la moitié de ceux installés.
Pour ton problème, tente de voir si tu arrives à quelque chose avec le TUI d'aptitude en simulant les installations manuelles des paquets que j'ai cité à la fin de mon message précédent. Cherche jusqu'à ce qu'il n'y ait plus de message d'erreur. Tu peux revenir en arrière dans le menu Action (Ctrl+t) > Annuler les actions en attente (raccourci en touche l)