En refaisant des tests, je me suis aperçu que j'ai omis de préciser une étape capitale pour que la carte Wifi soit correctement reconnue.
En plus de supprimer le paquet isc-dhcp-client, il faut également supprimer le paquet isc-dhcp-common qui lui aussi est installé automatiquement par debootstrap !
Et plus important encore, il faut préciser à Systemd de continuer l'amorçage du système sans attendre que toutes les interfaces soient configurée !
Pour cela, il faut créer le fichier /etc/systemd/system/systemd-networkd-wait-online.service.d/wait-for-only-one-interface.conf
bah systemd, dbus et les dépendances, c'est une échelle posée sur un escabeau pour aller plus haut
C'est vrai que c'est très hasardeux et j'ai du mal à comprendre les interactions entre ces différents éléments.
J'ai réglé ça en forçant le nommage des interfaces par des fichiers .link dans /etc/systemd/network/.
tu peux détailler ?
Oui, voilà les différents fichiers pour les deux ports Ethernet et le wifi :
Liste des fichiers dans /etc/systemd/network/ :
10-ethernet_WAN.link
11-ethernet_LAN.link
13-WIFI.link
20-ethernet_WAN.network
21-ethernet_LAN.network
23-WIFI.network
Dans les fichiers .link, les balises Path correspondent ici au matériel du Nanopi R5C.
Le Nanopi R5C sert de routeur en deuxième front de ma box internet avec une délégation d'adresse IPv6 de ::/56.
Contenu du fichier /etc/systemd/network/10-ethernet_WAN.link :
[Match]# Match path as exposed by the udev property ID_PATH (command: "udevadm info /sys/class/net/...")Path=platform-3c0800000.pcie-pci-0002:01:00.0
[Link]Name=wan0
MACAddress=B6:DC:0B:7A:BF:8A
Contenu du fichier _/etc/systemd/network/11-ethernet_LAN.link :
[Match]# Match path as exposed by the udev property ID_PATH (command: "udevadm info /sys/class/net/...")Path=platform-3c0400000.pcie-pci-0001:01:00.0
[Link]Name=lan0
MACAddress=CA:FE:00:BA:BE:00
Contenu du fichier _/etc/systemd/network/13-WIFI.link :
[Match]# Match path as exposed by the udev property ID_PATH (command: "udevadm info /sys/class/net/...")Path=platform-3c0000000.pcie-pci-0000:01:00.0
[Link]Name=wifi0
MACAddress=B0:B0:00:CA:FA:CE
Contenu du fichier _/etc/systemd/network/20-ethernet_WAN.network :
Cela est complété par démon d'annonce de routeurs (radvd), un serveur DHCP4 et DHCP6 (la suite kea) et un serveur de nom (named) qui sert de proxy vers le serveur DNS de la box internet.
Voici ce que donne la sortie de la commande ip a :
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: lan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether ca:fe:00:ba:be:00 brd ff:ff:ff:ff:ff:ff
3: wan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether b6:dc:0b:7a:bf:8a brd ff:ff:ff:ff:ff:ff
inet 192.168.0.40/24 metric 10 brd 192.168.0.255 scope global dynamic wan0
valid_lft 24430sec preferred_lft 24430sec
inet6 2a01:e0a:cafe:1234::efd1:9489/128 scope global dynamic noprefixroute
valid_lft 76094sec preferred_lft 76094sec
inet6 fe80::b4dc:bff:fe7a:bf8a/64 scope link
valid_lft forever preferred_lft forever
4: wifi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether b0:b0:00:ca:fa:ce brd ff:ff:ff:ff:ff:ff permaddr ec:2e:98:48:65:31
inet 10.0.1.254/8 brd 10.255.255.255 scope global wifi0
valid_lft forever preferred_lft forever
inet6 2a01:e0a:cafe:1234:b::/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::b2b0:ff:feca:face/64 scope link
valid_lft forever preferred_lft forever
Pour le moment, je n'ai rien branché côté LAN, d'où une interface pas complètement configurée.
Mais on voit bien les noms des différentes interfaces qui sont bien wan0, lan0 et wifi0.
ce serait bien d'avoir un schéma du déroulement de quand ça va bien et quand ça ne va pas bien pour fiabiliser définitivement quitte à mettre le nez dans le code :D
Ce serait avec plaisir, mais je ne sais pas comment faire.
En tout cas, ça me permettrait de mieux comprendre le phénomène…
La suppression du paquet isc-dhcp-client a pour une raison inconnue chahuté la nomination des interfaces réseaux.
J'ai réglé ça en forçant le nommage des interfaces par des fichiers .link dans /etc/systemd/network/.
Le système est maintenant stable et je confirme que c'était bien le paquet isc-dhcp-client qui posait problème.
Dans mon cas, ce dernier est automatiquement installé par debootstrap.
Lors de la création du debootstrap, il faut passer l'option "--exclude isc-dhcp-client".
[on a le droit aux grossièretés sur ce forum, car là ça me démange grâve !
Bon, je vais rester poli…]
"Oh miracle !"
Comme j'utilise le service DHCP client fourni par Systemd, j'ai désinstallé le paquet isc-dhcp-client…
Je reboote et là : "Oh miracle !"
La carte Wifi est directement reconnue sans avoir à forcer un rescan du bus PCI et le firmware rtw_8822ce est correctement chargé !!!
et après entré manuellement echo 1 > /sys/bus/pci/rescan :
[ 110.141825] pci 0000:01:00.0: [10ec:c822] type 00 class 0x028000
[ 110.399437] rtw_8822ce 0000:01:00.0: enabling device (0000 -> 0003)
[ 110.418755] rtw_8822ce 0000:01:00.0: firmware: direct-loading firmware rtw88/rtw8822c_wow_fw.bin
[ 110.419578] rtw_8822ce 0000:01:00.0: Firmware version 9.9.4, H2C version 15
[ 110.427681] rtw_8822ce 0000:01:00.0: firmware: direct-loading firmware rtw88/rtw8822c_fw.bin
[ 110.428462] rtw_8822ce 0000:01:00.0: Firmware version 9.9.15, H2C version 15
[ 110.441167] rtw_8822ce 0000:01:00.0: error beacon valid
[ 110.441676] rtw_8822ce 0000:01:00.0: failed to download rsvd page
[ 110.442235] rtw_8822ce 0000:01:00.0: failed to download firmware
[ 110.442910] rtw_8822ce 0000:01:00.0: failed to setup chip efuse info
[ 110.443476] rtw_8822ce 0000:01:00.0: failed to setup chip information
[ 110.467472] rtw_8822ce: probe of 0000:01:00.0 failed with error -16
Avant le forçage du rescan du bus PCI, je ne vois rien qui puisse concerner la carte Wifi…
Par contre, je vois qu'il y a du NetworkManager, et ça ce n'est pas normal car je ne l'ai pas volontairement installé et mes paramètres réseaux sont configurés avec Systemd-networkd.
et on voit apparaître le carte Wifi, mais le driver n'est pas en cours d'utilisation par le noyau (il manque le ligne "Kernel driver in use" pour la carte AzureWave).
Je recharge ensuite le module avec la commande modprobe -i rtw88_8822ce qui ne renvoie pas de message d'erreur et voici la sortie de la commande journalctl -f :
kernel: rtw_8822ce 0000:01:00.0: firmware: direct-loading firmware rtw88/rtw8822c_fw.bin
kernel: rtw_8822ce 0000:01:00.0: Firmware version 9.9.15, H2C version 15
kernel: rtw_8822ce 0000:01:00.0: firmware: direct-loading firmware rtw88/rtw8822c_wow_fw.bin
kernel: rtw_8822ce 0000:01:00.0: Firmware version 9.9.4, H2C version 15
kernel: rtw_8822ce 0000:01:00.0 wlp1s0: renamed from wlan0
systemd[1]: Starting systemd-rfkill.service - Load/Save RF Kill Switch Status…
systemd-networkd[270]: wlan0: Interface name change detected, renamed to wlp1s0.
systemd[1]: Started systemd-rfkill.service - Load/Save RF Kill Switch Status.
systemd[1]: systemd-rfkill.service: Deactivated successfully.
Merde ! Ça a fonctionné !!!
Mais pourquoi, ça n'a pas marché du premier coup ???
Voici la commande lspci -k -s 0000:01:00.0 qui montre que le firmware a bien été chargé et est utilisé par le kernel :
La question maintenant est de savoir pourquoi ça ne fonctionne pas du premier coup ???
Cela peut-il être dû à une mauvaise configuration de l'initramfs ?
Merci à toute l'équipe et à l'ensemble des contributeurs pour votre travail formidable.
C'est beaucoup grâce à vous si je me suis mis à Linux fin des années 90, même si j'ai mis très longtemps avant de m'inscrire sur le site.
J'y ai découvert la communauté du libre et ses valeurs et depuis Linux ne m'a jamais quitté.
À titre personnel, je ne suis jamais passé à Windows 98, ni à toute autre version ultérieure de Windows, sauf désespérément sous forme de machine virtuelle pour utiliser des applications dont je n'avais pas trouvé d'équivalent sous Linux. Mais aujourd'hui, je n'y ai plus du tout recours.
Alors "Vive le libre ! et longue vie à LinuxFr.org !!!"
Bonjour Thomas et merci beaucoup pour cette réponse très exhaustive !
Je n'avais pas compris que le lanceur fait les mises-à-jour automatiquement.
Je vais donc essayer ce dernier, mon fils et moi on est fan de Tremulous et on a hâte de passer à Unvanquished.
Je comprend aussi les difficultés et le temps nécessaire à maintenir des dépôts pour chaque distribution.
Si le lanceur est une méthode "propre", cela me convient.
Bravo à tous pour avoir repris et amélioré Tremulous.
Longue vie à Unvanquished !
Mais s'il vous plaît, prévoyez des paquets debian (.deb).
Quand on a un système stable et fiable et qu'on veut pouvoir continuer à le mettre à jour facilement, on n'aime pas du tout installer des archives zip.
Mais justement à propos de partage, comment te fais-tu connaître ?
Tu dis dans ton article que tu es "passée au côté obscur et as publié sur une plateforme non libre" pour revenir au monde libre avec le projet Kaosfantasy.
Mais à part cet article sur LinuxFR, utilises-tu d'autres plateformes pour faire connaître ton projet Kaosfantasy ?
Merci gepolabo pour cette présentation.
Mais toi au final, quelle(s) solution(s) as-tu retenu pour ton utilisation personnelle ?
Et comment l'as-tu hébergée ? (serveur hébergé chez un prestataire ?, serveur local ?)
Et avec quelle configuration ? (processeur, mémoire RAM, mémoire de stockage)
J'avais en effet déjà consulté le wiki de debian sur l'ASUS T100TA, qui montre qu'il n'est pas complètement supporté. Il y a des parties matérielles dont il manque les drivers compatibles.
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Problème pour charger le firmware Realtek rtw88. Évalué à 1.
Merci @BAud, mais cela dépasse malheureusement mes compétences.
# ERRATUM : Complément à la solution
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Problème pour charger le firmware Realtek rtw88. Évalué à 1.
ERRATUM : Complément à la solution
En refaisant des tests, je me suis aperçu que j'ai omis de préciser une étape capitale pour que la carte Wifi soit correctement reconnue.
En plus de supprimer le paquet isc-dhcp-client, il faut également supprimer le paquet isc-dhcp-common qui lui aussi est installé automatiquement par debootstrap !
Et plus important encore, il faut préciser à Systemd de continuer l'amorçage du système sans attendre que toutes les interfaces soient configurée !
Pour cela, il faut créer le fichier /etc/systemd/system/systemd-networkd-wait-online.service.d/wait-for-only-one-interface.conf
On commence par créer le répertoire ad-hoc :
et on crée dedans le fichier wait-for-only-one-interface.conf :
Le paramètre important ici est "--any" !
Et on redémarre le système !
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Problème pour charger le firmware Realtek rtw88. Évalué à 1.
Bonjour @BAud,
C'est vrai que c'est très hasardeux et j'ai du mal à comprendre les interactions entre ces différents éléments.
Oui, voilà les différents fichiers pour les deux ports Ethernet et le wifi :
Liste des fichiers dans /etc/systemd/network/ :
10-ethernet_WAN.link
11-ethernet_LAN.link
13-WIFI.link
20-ethernet_WAN.network
21-ethernet_LAN.network
23-WIFI.network
Dans les fichiers .link, les balises Path correspondent ici au matériel du Nanopi R5C.
Le Nanopi R5C sert de routeur en deuxième front de ma box internet avec une délégation d'adresse IPv6 de ::/56.
Contenu du fichier /etc/systemd/network/10-ethernet_WAN.link :
Contenu du fichier _/etc/systemd/network/11-ethernet_LAN.link :
Contenu du fichier _/etc/systemd/network/13-WIFI.link :
Contenu du fichier _/etc/systemd/network/20-ethernet_WAN.network :
Contenu du fichier _/etc/systemd/network/21-ethernet_LAN.network :
Contenu du fichier _/etc/systemd/network/23-WIFI.network :
Cela est complété par démon d'annonce de routeurs (radvd), un serveur DHCP4 et DHCP6 (la suite kea) et un serveur de nom (named) qui sert de proxy vers le serveur DNS de la box internet.
Voici ce que donne la sortie de la commande
ip a:Pour le moment, je n'ai rien branché côté LAN, d'où une interface pas complètement configurée.
Mais on voit bien les noms des différentes interfaces qui sont bien wan0, lan0 et wifi0.
Ce serait avec plaisir, mais je ne sais pas comment faire.
En tout cas, ça me permettrait de mieux comprendre le phénomène…
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Problème pour charger le firmware Realtek rtw88. Évalué à 1.
La suppression du paquet
isc-dhcp-clienta pour une raison inconnue chahuté la nomination des interfaces réseaux.J'ai réglé ça en forçant le nommage des interfaces par des fichiers .link dans /etc/systemd/network/.
Le système est maintenant stable et je confirme que c'était bien le paquet isc-dhcp-client qui posait problème.
Dans mon cas, ce dernier est automatiquement installé par debootstrap.
Lors de la création du debootstrap, il faut passer l'option "--exclude isc-dhcp-client".
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Problème pour charger le firmware Realtek rtw88. Évalué à 1.
Je me fais des fausses joies.
En fait, la détection de la carte Wifi est totalement aléatoire et n'est pas assurée à chaque redémarrage du serveur NanoPi R5C.
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Problème pour charger le firmware Realtek rtw88. Évalué à 1.
[on a le droit aux grossièretés sur ce forum, car là ça me démange grâve !
Bon, je vais rester poli…]
"Oh miracle !"
Comme j'utilise le service DHCP client fourni par Systemd, j'ai désinstallé le paquet isc-dhcp-client…
Je reboote et là : "Oh miracle !"
La carte Wifi est directement reconnue sans avoir à forcer un rescan du bus PCI et le firmware rtw_8822ce est correctement chargé !!!
C'était le service isc-dhcp-client qui posait problème !!!
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Problème pour charger le firmware Realtek rtw88. Évalué à 1.
Après vérification, NetworkManager n'est pas installé :
aptitude search '~i network'ne renvoie rien./usr/lib/NetworkManager/ n'existe pas :
Le fichier de configuration en question est /etc/apparmor.d/sbin.dhclient qui vient du paquet isc-dhcp-client.
-> Fausse alerte…
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Problème pour charger le firmware Realtek rtw88. Évalué à 1.
@BAud, voici la sortie de la commande demandée :
et après entré manuellement
echo 1 > /sys/bus/pci/rescan:Avant le forçage du rescan du bus PCI, je ne vois rien qui puisse concerner la carte Wifi…
Par contre, je vois qu'il y a du NetworkManager, et ça ce n'est pas normal car je ne l'ai pas volontairement installé et mes paramètres réseaux sont configurés avec Systemd-networkd.
# lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Problème pour charger le firmware Realtek rtw88. Évalué à 1.
Fait certainement non anodin,
lspcine détecte pas la carte Wifi sans forcer un rescan du bus.Après un reboot, voici ce que donne la commande
lspci -knn:Il faut alors entrer la commande suivante pour forcer un nouveau scan du bus PCI :
La sortie de
journalctl -faffiche le message d'erreur :Mais la commande
lspci -knndonne maintenant :et on voit apparaître le carte Wifi, mais le driver n'est pas en cours d'utilisation par le noyau (il manque le ligne "Kernel driver in use" pour la carte AzureWave).
[^] # Re: plutôt le firmware
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Problème pour charger le firmware Realtek rtw88. Évalué à 1. Dernière modification le 14 janvier 2024 à 22:08.
Voici la sortie de la commande
lsmodavant la désinstallation des modules :Je désinstalle les modules :
Je réadapte la commande :
qui ne génère pas d'erreur.
journalctl -fne renvoie rien non plus.Je refais un
lsmod:Je recharge le module :
Je réadapte la commande :
qui ne génère pas d'erreur.
La sortie de
journalctl -fdonne :Le firmware refuse encore une fois de se charger.
Je redonne la sortie de la commande
lsmod:[^] # Re: plutôt le firmware
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Problème pour charger le firmware Realtek rtw88. Évalué à 1.
Je vais essayer de prendre dans l'ordre…
La sortie de la commande
lspci -k -nn:La sortie de la commande
rfkill list:La sortie de la commande
modinfo rtw_8822cerenvoie un message d'erreur :Je te donne le résultat d'une recherche générale sur le motif "rtw" :
rtw_8822ce est le nom d'un driver qui pour moi provient de /usr/lib/firmware/rtw88/rtw8822c_fw.bin
[^] # Re: plutôt le firmware
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Problème pour charger le firmware Realtek rtw88. Évalué à 1.
ARG ! Au secours !
J'ai redémarré le Nanopi R5C et recommencé la procédure, mais ça ne fonctionne plus !
Lorsque je supprime le module par la commande
modprobe -r rtw88_8822ce, je n'ai plus les logs indiquant la désactivation de RFKILL.C'est peut-être là le problème… RFKILL ne se charge peut-être pas correctement et empêche l'activation du driver rtw_8822ce ???
Lorsque je recharge le module par la commande
modprobe -i rtw88_8822ce, j'ai de nouveau les messages d'erreurs de chargement du module :et depuis impossible de recharger correctement le firmware…
[^] # Re: plutôt le firmware
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Problème pour charger le firmware Realtek rtw88. Évalué à 1.
Merci @Baud pour ton retour.
Voici la sortie de la commande
uname -a:Voici la sortie de la commande
journalctl -fsuite à l'activation de la commandemodprobe -r rtw88_8822ce:La commande
modprobe -r rtw88_8822cen'a pas retournée de message d'erreur.Voici la sortie de la commande
lsmod |grep -iE "rtw|mac|80211":Je recharge ensuite le module avec la commande
modprobe -i rtw88_8822cequi ne renvoie pas de message d'erreur et voici la sortie de la commandejournalctl -f:Merde ! Ça a fonctionné !!!
Mais pourquoi, ça n'a pas marché du premier coup ???
Voici la commande
lspci -k -s 0000:01:00.0qui montre que le firmware a bien été chargé et est utilisé par le kernel :Et pour aller jusqu'au bout, voici la sortie de la commande
modinfo rtw88_8822ce:La question maintenant est de savoir pourquoi ça ne fonctionne pas du premier coup ???
Cela peut-il être dû à une mauvaise configuration de l'initramfs ?
# Merci à tous
Posté par libresurf (site web personnel, Mastodon) . En réponse à la dépêche Vingt-quatre ans de LinuxFr.org. Évalué à 10.
Merci à toute l'équipe et à l'ensemble des contributeurs pour votre travail formidable.
C'est beaucoup grâce à vous si je me suis mis à Linux fin des années 90, même si j'ai mis très longtemps avant de m'inscrire sur le site.
J'y ai découvert la communauté du libre et ses valeurs et depuis Linux ne m'a jamais quitté.
À titre personnel, je ne suis jamais passé à Windows 98, ni à toute autre version ultérieure de Windows, sauf désespérément sous forme de machine virtuelle pour utiliser des applications dont je n'avais pas trouvé d'équivalent sous Linux. Mais aujourd'hui, je n'y ai plus du tout recours.
Alors "Vive le libre ! et longue vie à LinuxFr.org !!!"
[^] # Re: Des paquets .deb ?
Posté par libresurf (site web personnel, Mastodon) . En réponse à la dépêche Unvanquished 0.52 Beta est là. Évalué à 2.
Bonjour Thomas et merci beaucoup pour cette réponse très exhaustive !
Je n'avais pas compris que le lanceur fait les mises-à-jour automatiquement.
Je vais donc essayer ce dernier, mon fils et moi on est fan de Tremulous et on a hâte de passer à Unvanquished.
Je comprend aussi les difficultés et le temps nécessaire à maintenir des dépôts pour chaque distribution.
Si le lanceur est une méthode "propre", cela me convient.
Merci à vous.
# Des paquets .deb ?
Posté par libresurf (site web personnel, Mastodon) . En réponse à la dépêche Unvanquished 0.52 Beta est là. Évalué à 2.
Bravo à tous pour avoir repris et amélioré Tremulous.
Longue vie à Unvanquished !
Mais s'il vous plaît, prévoyez des paquets debian (.deb).
Quand on a un système stable et fiable et qu'on veut pouvoir continuer à le mettre à jour facilement, on n'aime pas du tout installer des archives zip.
Ou sinon, avez-vous pensé à Flatpak ou à Snapcraft ?
# Comment te fais-tu connaître ?
Posté par libresurf (site web personnel, Mastodon) . En réponse à la dépêche Projet Kaosfantasy et libération de trois séries de fantasy : plus de 5000 pages. Évalué à 3.
Merci Kaoseto pour ton partage.
Mais justement à propos de partage, comment te fais-tu connaître ?
Tu dis dans ton article que tu es "passée au côté obscur et as publié sur une plateforme non libre" pour revenir au monde libre avec le projet Kaosfantasy.
Mais à part cet article sur LinuxFR, utilises-tu d'autres plateformes pour faire connaître ton projet Kaosfantasy ?
# Et ton choix final ?
Posté par libresurf (site web personnel, Mastodon) . En réponse à la dépêche Alternatives pour un réseau social familial. Évalué à 7.
Merci gepolabo pour cette présentation.
Mais toi au final, quelle(s) solution(s) as-tu retenu pour ton utilisation personnelle ?
Et comment l'as-tu hébergée ? (serveur hébergé chez un prestataire ?, serveur local ?)
Et avec quelle configuration ? (processeur, mémoire RAM, mémoire de stockage)
[^] # Re: Export du fichier des écritures comptables - Fichier FEC
Posté par libresurf (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Tryton 5.0. Évalué à 1.
Génial !
Merci pour cette information capitale.
# Export du fichier des écritures comptables - Fichier FEC
Posté par libresurf (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Tryton 5.0. Évalué à 4.
Bonjour,
est-ce que Tryton permet l'export du fichier des écriture comptables (dit "fichier FEC") qui est devenu obligatoire en France pour toute société ?
Ce fichier doit avoir un format particulier et doit répondre au cahier des charges du FISC :
http://bofip.impots.gouv.fr/bofip/9028-PGP
[^] # Re: Quel portable 11,6 pouces ?
Posté par libresurf (site web personnel, Mastodon) . En réponse au journal Remboursement de Windows 10 sur un PC portable Asus. Évalué à 1.
oui, je confirme.
C'est la raison pour laquelle je n'ai pas encore sauté le pas…
https://linuxfr.org/forums/general-cherche-materiel/posts/votre-retour-d-experience-sur-des-portables-hybrides-2-en-1-avec-ecran-tactile
[^] # Re: ces modèles ne sont pas listés sur
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Votre retour d'expérience sur des portables hybrides 2-en-1 avec écran tactile ?. Évalué à 1.
Merci palm123,
merci pour ces liens et ces informations.
J'avais en effet déjà consulté le wiki de debian sur l'ASUS T100TA, qui montre qu'il n'est pas complètement supporté. Il y a des parties matérielles dont il manque les drivers compatibles.
[^] # Re: ma vie avec le Envy-X2
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Votre retour d'expérience sur des portables hybrides 2-en-1 avec écran tactile ?. Évalué à 1.
Bonjour NeoX,
merci pour ce retour fort utile.
[^] # Re: CremeCRM
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Quel CRM libre choisir aujourd'hui ?. Évalué à 1.
En fait, il s'agit de pkg-config.
[^] # Re: CremeCRM
Posté par libresurf (site web personnel, Mastodon) . En réponse au message Quel CRM libre choisir aujourd'hui ?. Évalué à 1.
J'ai trouvé la solution sur stackoverflow.
Avant d'exécuter la commande :
pip install -r requirements.txt, il faut installer le paquet dpk-config !!! :# aptitude install dpkg-config