Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 Re : Matériel » Écran noir Bullseye portable Asus X73SV GPU Nvidia GT504M » 12-04-2022 11:22:21

Up !
Quelqu'un a t-il une idée ?
C'est quand même malheureux que depuis que cette technologie Optimus existe, elle soit aussimal gérée par Debian ...
Dois-je faire comme sur ce post https://debian-facile.org/viewtopic.php?id=31773 ? Passer sous Ubuntu ? Alors que je suis sous Debian depuis presque 15 ans ...

#2 Re : Matériel » Écran noir Bullseye portable Asus X73SV GPU Nvidia GT504M » 05-04-2022 08:51:30

" tu ne peut pas utiliser bumblebee avec le pilote du site nvidia" : "Enfin sous Buster, avec le pilote nvidia (390.138) pêché sur leur site et bumblebee, tout fonctionnait correctement : optirun avec glxgears, avec blender, etc."
"tu ne peu pas installer le pilote du site nvidia si tu n'a pas les prés-requis au niveau des versions de paquets et du noyau , et si ta carte n'est pas compatible avec ce driver ." : pourtant si, avec ma réponse ci-dessus et bien sûr en choississant le driver correspondant à ma carte.
"le driver nvidia nonfree des dépôt debian est configuré pour fonctionner avec la version de debian pour laquelle il est prévu . " :  Il me semblait que le rétroportage revenait à une compilation du paquet source sur le système avec toutes ses dépendances.

#3 Re : Matériel » Écran noir Bullseye portable Asus X73SV GPU Nvidia GT504M » 04-04-2022 21:52:49

primusrun glxinfo -B
primus: fatal: failed to connect to Bumblebee daemon: No such file or directory
 


Avec root :

systemctl restart bumblebeed


Pas d'erreur

primusrun glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 11.0.1, 256 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 20.3.5
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.1 Mesa 20.3.5
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
 


bloc à supprimer si la commande n’affiche rien

#4 Re : Matériel » Écran noir Bullseye portable Asus X73SV GPU Nvidia GT504M » 04-04-2022 21:42:31

glxinfo -B :

glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 3000 (SNB GT2) (0x116)
    Version: 20.3.5
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 3000 (SNB GT2)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 20.3.5
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 20.3.5
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 20.3.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
 

#5 Re : Matériel » Écran noir Bullseye portable Asus X73SV GPU Nvidia GT504M » 03-04-2022 14:30:01

D'un autre coté, il est vrai qu'avec le pilote nvidia en provenance du site nvidia, j'aurais à vérifier systématiquement les versions du pilote lors des màj de bullseye.
J'aimerai donc trouver une solution avec les dépôts debian. Et surtout comprendre pourquoi le rétroportage de cette pourtant identique version 390.147 ne fonctionne qu'à moitié.

#6 Re : Matériel » Écran noir Bullseye portable Asus X73SV GPU Nvidia GT504M » 02-04-2022 14:50:34

Merci de vos réponses.
Pour l'instant, j'ai récupéré ma session graphique en passant nomodeset au noyau.
J'ai fini par installer le dernier pilote depuis le site nvidia car le legacy des dépots debian ne passe pas. Mais je n'arrive pas à utiliser bumblebee, seul le gpu intégré Intel est actif (vu avec clinfo) et j'ai testé avec supertuxkart, ça rame dès que c'est un peu trop chargé.
J'ai aussi essayé d'installer la même version de ce pilote nvidia par rétroportage de la version de Sid. Aucune erreur lors de l'installation, sddm se lance correctement, KDE s'ouvre sur Firefox que j'avais laissé ouvert, mais plus de bureau .... kernal_panic.gif. C'est pourtant bien la même version que celui de Nvidia (390.147).

Je vérifierai pour xorg ou wayland. Mais je pense que je suis sous xorg. (Je ne suis pas sur mon ordi en ce moment)

D'après les posts sur Debian.fr et d'autres, Bullseye aurait dû amener plus de simplicité avec Optimus. Je constate juste que c'est pire qu'avec Buster.

@robert2a, j'ai déjà vérifié et réinstallé firmware-misc-nonfree, le noyau et les headers. Je vérifierai pour xserver-xorg-video-all. Le pilote intel i915 doit être déjà installé puisque c'est ce gpu qui tourne.
Je ne veux pas de nouveau comme pilote.
Enfin sous Buster, avec le pilote nvidia (390.138) pêché sur leur site et bumblebee, tout fonctionnait correctement : optirun avec glxgears, avec blender, etc.

Voilà, voilà ...
En tout cas, encore merci pour vos réponses.

#7 Matériel » Écran noir Bullseye portable Asus X73SV GPU Nvidia GT504M » 31-03-2022 18:04:07

Maufab
Réponses : 9
Bonjour,
Le portable : Asus X73SV avec deux cartes graphiques, Intel et Nvidia GT540M.

suite à une màj de Buster vers Bullseye, et après avoir voulu réinstaller Bumblebee, je me retrouve avec un écran noir avec le curseur clignotant en haut à gauche et disparition  des tous les tty. Donc plus d'accès au système par Ctrl-Alt-F1-6.
Je précise qu'après la màj du système, j'ai eu un démarrage normal en session graphique.

Sous Buster, j'avais fait fonctionner bumblebee avec le pilote propriétaire nvidia 390.148.run téléchargé chez nvidia, car le pilote legacy 390xx du dépot debian ne passait pas.
Lorsque j'ai voulu utiliser optirun sous bullseye, celui-ci était inopérant. J'ai donc refait une install de bumblebee depuis le début en commençant par purger les paquets nvidia et en réinstallant le pilote nvidia 390.148.run. Ce dernier a refusé de s'installer. Après un nvidia detect, j'ai donc installer celui du dépot debian nvidia-legacy-390xx malgré le fait qu'il me dise que ce pilote n'est pas compatible avec ma carte gt540m. Pendant l'installation, j'ai perdu la session graphique avec écran noir et suis obligé pour redémarrer de passer par l'extinction du portable en pressant le bouton power.
En passant par le mode rescue, j'ai tout purger à nouveau, installé le pilote nouveau, désinstallé le pilote nouveau et vga_switcheroo, etc.
J'ai cherché dans journactl, dans les firmwares, un peu partout, ... Rien qui m'indique quoi que ce soit. Un doute quand même concernant wayland et Xorg.
Voilà, je sollicite votre aide.

#8 Re : Système » Raid1 nom de groupe md127 » 09-01-2022 21:22:37

Merci de ta réponse.
Comme je réinstalle windows en double boot, j'ai été obligé de virer le raid suer les partitions efi. Du coup c'est redevenu propre. smile

#9 Système » Raid1 nom de groupe md127 » 02-01-2022 19:07:03

Maufab
Réponses : 2
Bonjour et bonne année.
Suite  au crash d'un disque partitionné en GPT (/dev/sda) sur lequel j'avais grub et refind sur 2 partions EFI non RAID, dans un raid1  j'ai remplacé le disque et relancé le système avec succès. J'ai aussi relancé le raid en ajoutant les partitions EFI jumelles au raid (/dev/sda1 et /dev/sdb1). Comme j'ai perdu le chargeur de démarrage EFI avant de redémarrer,  je n'ai pas pu redémarrer Debian. Je me suis lancé dans une récupération depuis un live cd Sysrescue avec un chroot. J'ai réussi la manoeuvre mais ça m'a mis le bazard dans les nom de groupes RAID et l'étiquette des partions RAID (labellisées maintenant sysrescue:0,1, etc)
Pour remettre de l'ordre dans les noms de groupes raid, j'ai tenté plusieurs fois de réassembler les goupes concernés sous le sytème natif (Debian 10), sans pouvoir stopper le raid (ressources occupées). Il me semble avoir déjà eu à faire avec ce changements de noms de groupes et pouvoir stopper un raid actif. Mais je peux me tromper d'où mon questionnement : est-il possible de stopper un raid actif  pour changer les noms de groupes?
Depuis un live cd, oui, avec ce problème de changement de noms. Mais depuis le système concerné ?

# fdisk -l              
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ST1000LM049-2GH1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 8B860C74-9AC3-11EB-BBDA-E2070740347B

Device         Start        End    Sectors   Size Type
/dev/sda1       4096    1048575    1044480   510M EFI System
/dev/sda2    1048576  158744575  157696000  75.2G Microsoft basic data
/dev/sda3  554008576  558104575    4096000     2G Linux RAID
/dev/sda4  558104576  640024575   81920000  39.1G Linux RAID
/dev/sda5  640024576 1953523711 1313499136 626.3G Linux RAID
/dev/sda6  158744576  554008575  395264000 188.5G Microsoft basic data

Partition table entries are not in disk order.


Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ST1000LM049-2GH1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 8B860C74-9AC3-11EB-BBDA-E2070740347B

Device         Start        End    Sectors   Size Type
/dev/sdb1       4096    1048575    1044480   510M EFI System
/dev/sdb2    1048576  554008575  552960000 263.7G Linux filesystem
/dev/sdb3  554008576  558104575    4096000     2G Linux RAID
/dev/sdb4  558104576  640024575   81920000  39.1G Linux RAID
/dev/sdb5  640024576 1953523711 1313499136 626.3G Linux RAID




Disk /dev/md127: 510 MiB, 534708224 bytes, 1044352 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000


Disk /dev/md126: 2 GiB, 2095054848 bytes, 4091904 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/md125: 39 GiB, 41908436992 bytes, 81852416 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/md124: 626.2 GiB, 672376291328 bytes, 1313234944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes




# mdadm --examine --scan
ARRAY /dev/md/0  metadata=1.0 UUID=6c2cbbac:79178666:41d04bc1:7b40dc5e name=sysrescue:0
ARRAY /dev/md/1  metadata=1.2 UUID=bd31a2d4:b2492675:209e0885:6d3189a7 name=sysrescue:1
ARRAY /dev/md/1  metadata=1.2 UUID=bbf65afd:f50cd4a7:6ea255ff:01117b68 name=fabport:1
ARRAY /dev/md/3  metadata=1.2 UUID=4a5c9536:85a48fc6:c4e04261:7a3c4c8b name=sysrescue:3



# cat /proc/mdstat
Personalities : [raid1]
md124 : active (auto-read-only) raid1 sda5[2] sdb5[1]
      656617472 blocks super 1.2 [2/2] [UU]
      bitmap: 0/5 pages [0KB], 65536KB chunk

md125 : active raid1 sda4[2] sdb4[1]
      40926208 blocks super 1.2 [2/2] [UU]
     
md126 : active (auto-read-only) raid1 sda3[2] sdb3[1]
      2045952 blocks super 1.2 [2/2] [UU]
     
md127 : active raid1 sda1[2] sdb1[1]
      522176 blocks super 1.0 [2/2] [UU]
     
unused devices: <none>



# mdadm -D /dev/md124
/dev/md124:
           Version : 1.2
     Creation Time : Tue Oct 27 04:05:11 2020
        Raid Level : raid1
        Array Size : 656617472 (626.20 GiB 672.38 GB)
     Used Dev Size : 656617472 (626.20 GiB 672.38 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Sun Jan  2 16:50:37 2022
             State : clean
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : sysrescue:3  (local to host sysrescue)
              UUID : 4a5c9536:85a48fc6:c4e04261:7a3c4c8b
            Events : 61422

    Number   Major   Minor   RaidDevice State
       2       8        5        0      active sync   /dev/sda5
       1       8       21        1      active sync   /dev/sdb5

#11 Re : Scripts, programmes et robots » [Résolu] rechercher-remplacer série de nombres incrémentés » 20-05-2021 18:57:09

Merci pour vos réponses. Je regarderai ça de plus près.
En attendant, j'ai utilisé une série de pipes pour la recherche : ^\d{1}$ | ^\d{2}$ | ^\d{3}$
que je pense faire suivre d'une boucle incrémentale.
Ce n'est peut-être pas ce qu'il y a le plus élégant.
Le Perl, je ne maitrise pas. Je me sens plus à l'aise avec le bash ou C bien que je n'ai pas pratiqué depuis un moment. D'où mes hésitations.
@enicar, j'ai utilisé le mode expressions régulières dans Kate. La boucle while, c'est une boucle infinie ? Une boucle for ne serait-elle pas plus adaptée ?

#12 Scripts, programmes et robots » [Résolu] rechercher-remplacer série de nombres incrémentés » 20-05-2021 11:24:42

Maufab
Réponses : 5
Bonjour,
dans un fichier .srt, chaque partie est numérotée de 1 à par ex. 495. À partir de 2 fichiers. srt je veux n'en faire qu'un seul. Et donc reprendre la numérotation du second depuis le dernier numéro du 1er fichier. Donc utiliser les expressions régulières. J'ai commencé avec celle-ci : ^\d{3} mais qui bien sûr ne m'affiche que les nombres à 3 chiffres. Comment faire pour afficher tous les nombres de 1 à 495 ? Et bien sûr remplacer ceux du second fichiers en suivant ceux du premier ?

#13 Re : Scripts, programmes et robots » Script bash cliquable sous LXQT » 03-07-2020 21:32:13

enicar a écrit :

Alors, c'est curieux d'arriver à te connecter avec wpa_supplicant et pas avec wicd ou
Network manager. Quand une carte est bloquée, on peut la « rfkill unblock ».
Si elle est bloquait de manière hard, il faut appuyer sur le bouton adéquat.
Quelques fois c'est un peu alambiqué avant d'y arriver, mais ça devrait fonctionner.
Il y a longtemps que je n'ai pas touché à ces outils car je n'utilise pas d'ordi portable
et pas non plus le wifi. Mais ça avait fonctionné à l'époque où je m'étais servi des outils
wicd et rfkill.



En fait, comme je l'ai écrit plus haut, ces scripts bash je les fait en attendant de résoudre mon problème avec le service systemd rfkill_unblock_all.service qui ne fonctionne pas au boot, mais qui fonctionne pourtant bien si je le relance manuellement. L'utilisateur n'a pas de grande connaissance en ligne de commande, alors je pensais lui faire deux scripts cliquables qui sont exécutés dans le terminal. Je n'ai pas dit que je n'y arrivais pas avec wicd ou network-manager, plutôt que je sais bien utiser wpa_supplicant  par habitude vu que j'avais passé la gestion de mon réseau sous systemd avec wpa_supplicant. Tout simplement je vais au plus simple pour moi avec mes connaissance. De plus, fut une époque où network-manager déconnait complètement sur ma machine.

#14 Re : Scripts, programmes et robots » Script bash cliquable sous LXQT » 02-07-2020 21:14:33

Merci Crouton et les autres. Avec les guillemets doubles, ça fonctionne, en tout cas sous KDE, puisque j'ai rendu le portable sous LXQT au copain qui se débrouille en attendant avec les instructions que je lui ai fourni et la ligne de commande roll :

#! /bin/bash
read -p "Entre le nom de la box : " ssid
read -p "Entre le mot de passe : " wpa
sudo sh -c "wpa_passphrase $ssid $wpa >>/etc/wpa_supplicant/wpa_supplicant-wlp7s0.conf"



Quant à wicd ou Network manager, tant que la carte wifi est dans l'état bloqué, avec rfkill list, je ne vois pas comment les utiliser. Et comme je connais mieux wpa_supplicant, voilà.

#15 Re : Scripts, programmes et robots » Script bash cliquable sous LXQT » 02-07-2020 08:34:03

Philou92 a écrit :

Peut-on voir la rédaction du service systemd rfkill_unblock_all ?


Bien sûr :

[Unit]
Description=
Before=network-pre.target
Wants=network-pre.target
Before=wpa_supplicant@wlp7s0.service

[Service]
#Type=oneshot
#RemainAfterExit=yes
Restart=on-failure

ExecStart=/usr/sbin/rfkill unblock all

[Install]
WantedBy=multi-user.target
 


et wpa_supplicant@wlp7s0.service :


[Unit]
After=rfkill_unblock.service
#After=network.target
Wants=rfkill_unblock.service
Before=network.target
Before=network-online.target

[Service]

#ExecStart=/root/wifi_connect.sh
ExecStart=/usr/sbin/wpa_supplicant -B -i wlp7s0 -c /etc/wpa_supplicant/wpa_supplicant-wlp7s0.conf
ExecStartPost=/usr/bin/systemctl restart systemd-networkd-wait-online.service

[Install]
WantedBy=multi-user.target
 

#16 Re : Scripts, programmes et robots » Script bash cliquable sous LXQT » 02-07-2020 08:29:40

Croutons a écrit :

Hello
Essai

#! /bin/bash
# this is declare that current user is a sudoer
#sudo tee /etc/sudoers.d/$USER <<END
#END

read -p "Entre le nom de la box : " ssid
read -p "Entre le mot de passe : " wpa
sudo sh -c 'wpa_passphrase $ssid $wpa >>/etc/wpa_supplicant/wpa_supplicant-wlp7s0.conf'
read



ou avec la commande tee (voir man tee)

echo 'wpa_passphrase $ssid $wpa' | sudo  tee -a /etc/wpa_supplicant/wpa_supplicant-wlp7s0.conf



Ni l'un, ni l'autre ne le fait. Dans le premier cas, que ce soit en lançant le script depuis un terminal ou en cliquant sur le fichier, j'ai en fin de fichier wpa_supplicant_wlp7s0.conf ceci : usage: wpa_passphrase <ssid> [passphrase] car je pense que les variables $ssid et $wpa ne sont pas prises en compte à l'intérieur de sh -c '...'.
Dans le second, ça m'écrit 'wpa_passphrase $ssid $wpa  dans le même fichier.

#17 Scripts, programmes et robots » Script bash cliquable sous LXQT » 01-07-2020 20:27:05

Maufab
Réponses : 17
Bonsoir,
Afin de faciliter la configuration d'une connexion wifi par wpa_passphrase à l'utilisateur, je lui ai créé un script cliquable sur le bureau. Ceci en attendant de trouver une solution avec un service systemd au boot.
Si j'exécute le script depuis le terminal via sudo, aucun problème. Mais lorsque je clique sur le script en le faisant exécuter dans un terminal, malgré le sudo en début de ligne, il me répond Permission non accordée pour écrire dans le fichier /etc/wpa_supplicant/wpa_supplicant-wlp7s0.conf


#! /bin/bash

# this is declare that current user is a sudoer
#sudo tee /etc/sudoers.d/$USER <<END
#END

echo "Entre le nom de la box : "
read ssid
echo "Entre le mot de passe : "
read wpa
echo $ssid $wpa
sudo wpa_passphrase $ssid $wpa >>/etc/wpa_supplicant/wpa_supplicant-wlp7s0.conf
read
 



Là, je coince.
Je précise que tout ça parce que la machine est un portable Acer 7250 avec carte wifi Atheros AR9425 kernel driver ath9k qui présente un soft et hard blocked.  Le service systemd rfkill_unblock_all que j'ai écris ne débloque rien au boot, il faut donc que je le relance manuellement pour pouvoir activer la carte. Donc pas moyen d'utiliser Networkmanager. La raison pour laquelle je passe par wpa_supplicant.
Merci d'avance.

#18 Re : Réseau » [Résolu] Client léger ltps » 07-04-2016 15:39:10

Bonjour, j'aimerai savoir où trouver la doc qui explique comment fonctionne réellement ltsp : protocoles réseau principalement. Je n'ai pas trouvé grand chose pour l'instant à part sur la doc chargée avec ltsp-docs et surhttps://help.ubuntu.com/community/UbuntuLTSP. Et surtout je me demande comment construire un chroot dont l'environnement est différent de celui de l'hôte comme par exemple une Primtux i386 dans une Debian amd64 headless?

#19 Re : Autres » virtualbox et debian 6.0 » 21-02-2011 19:40:30

si tu es en x86-64, ça vaut peut-être le coup d'essayer les fonction de virtualisation du noyau avec kvm et qemu. 9a fonctionne certainement bien mieux que virtualbox et tout ses petits pbs de configuration des interfaces réseaux et autres

#20 Re : Matériel » Touchpad non fonctionnel {RÉSOLU} » 09-02-2011 12:47:04

Peux -tu indiquer ta soluce? Je suis curieux.

#21 Re : Matériel » Touchpad non fonctionnel {RÉSOLU} » 08-02-2011 17:30:50

Et ça tu l'a essayé?:

Debian squeeze, kernel 2.6.30-1, Xorg 7.4

If you are using a generic synaptic touchpad, but it fails to respond to tapping or scrolling actions under a new installation of Squeeze (as in testing), you can run the following two commands to immediately make it work:

modprobe -r psmouse
modprobe psmouse proto=imps

To make this change permanent, create a file such as touchpad.conf under /etc/modprobe.d/, and put the following line in it:

options psmouse proto=imps

You do not need to install gsynptics, synaptic, tpconfig or edit xorg.conf. All you need is passing the kernel options for module psmouse.

#23 Re : Matériel » Touchpad non fonctionnel {RÉSOLU} » 08-02-2011 16:57:15

Alors, comme je viens juste de passer de kde à awesome (pub!), laisse moi le temps de retrouver la doc....
http://wiki.debian.org/SynapticsTouchpa … nxorg.conf

En fait, il ne fonctionne pas du tout ou bien tu n'as plus le tapping & scrolling?

Fabrice

#24 Re : Matériel » Touchpad non fonctionnel {RÉSOLU} » 08-02-2011 16:31:54

Le modèle du touchpad, si c'est un synaptics, je peux t'aider.

#25 Re : Matériel » [Résolu en partie] Imprimante HP Deskjet F2480 et pilote hplip-3.10.2 » 26-03-2010 19:59:40

oui, mais le tuto de chez HP http://hplipopensource.com/hplip-web/in … ebian.htmlest à corriger, au moins pour l'erreur de cups avec foomatic-rip-hplip dans ./configure pour
64 bit distro users:

./configure --with-hpppddir=/usr/share/ppd/HP --libdir=/usr/lib64 --prefix=/usr --enable-qt4 --enable-doc-build --disable-cups-ppd-install --disable-foomatic-drv-install --disable-foomatic-ppd-install --disable-hpijs-install --disable-policykit --enable-cups-drv-install --enable-hpcups-install --enable-network-build --enable-dbus-build --enable-scan-build --enable-fax-build


que j'ai remplacé par :

./configure --with-hpppddir=/usr/share/ppd/HP --libdir=/usr/lib64 --prefix=/usr --enable-qt4 --enable-doc-build --disable-cups-ppd-install --disable-foomatic-drv-install --enable-foomatic-ppd-install --enable-hpijs-install --disable-policykit --enable-cups-drv-install --enable-hpcups-install --enable-network-build --enable-dbus-build --enable-scan-build --enable-fax-build --disable-foomatic-rip-install --enable-foomatic-rip-hplip-install


comme indiqué ici: http://hplipopensource.com/node/337

L'erreur sur python-qt4-dbus, et bien je pense que de toute façon ce paquet est seulement nécessaire pour l'interface graphique de l'appli HP. Donc ça n'emp&#7871;che pas d'imprimer. Peut-être que ça peut être génant pour gérer les niveaux d'encre en mode graphique.

Pied de page des forums

Propulsé par FluxBB