Une place pour une véritable innovation. Partagez vos propres utilitaires créés avec la communauté Manjaro.
Questions et discussions sur la programmation et le codage.
pacdiff a des options
entre autre -d qui lui aussi fait une recherche à partir de la base de donnée et ... c'est justement ce qu'il utilise par défaut !
--------------------------
Sinon j'ai vu une remarque à l'inter qui pose problème :
Nous pouvons aussi avoir des fichiers de configuration dans notre home !!!
Et là, il y a un gros problème : pacman ne détecte rien, pas de pacnew MAIS nous pouvons nous retrouver avec un fichier config dans home qui n'est plus bon
Comme exemple, nous pouvons avoir un yaourtrc ou un makepkg.conf (c'est mon cas pour ces deux). Le problème ici c'est qu'il n'y a pas de norme, à part se trouver parfois dans .config donc il n'est pas possible de les retrouver automatiquement
Je vais troller un peu comme d'habitude
Mais là, je patauge les gars.
J'essaie de comprendre depuis hier tout ce que vous indiquez.
J'ai installé votre logiciel qui fonctionne très bien, mais je n'y comprends RIEN
J'ai bien des pacnew et des pacsave qui s'affichen, mais parfois les nouveaux (fenêtre de droite) ajoute des lignes ou en suppeime par rapport au .config, ce qui fait que je n'ose bouger à rien.
Système : Manjaro XFCE LTS CPU : 6 x Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz Carte graphique : NVIDIA Corporation GP107 [GeForce GTX 1050] (rev a1) Cartes son : Audio device: Intel Corporation Cannon Lake PCH cAVS (rev 10)
Audio device: NVIDIA Corporation GP107GL High Definition Audio Controller (rev a1)
ici on ne va pas donner des recettes, ce n'est pas le sujet !
Rassure toi c'est tout à fait normal de ne rien comprendre : il faut être dans la tête du développeur du logiciel qui génère le .pacnew ! donc pas le choix, il faut se taper la documentation (en) via le man ou avec de la chance dans le wiki archlinux.
---------------
Oui, pas de gestion des pacsave (il n'y a rien à fusionner sauf si on réinstalle le paquet) et les pacoring n'existent plus depuis un bon moment
Plus globalement, cet utilitaire liste les fichiers de configurations système qui ont été modifiés. Il donne un aperçu des modifications sans intervenir directement mais invoque des softs comme diffuse ou autres pour le faire. C'est plus simple que de le faire à la main . Après , la difficulté reste de savoir ce qu'il faut faire ou pas.... Au moins, on a un aperçu rapide de l'état des lieux.
Noyau récent MANJARO x86_64 bits: 64 Xfce 4.16
ASUSTeK model: PRIME B350M-A v: Rev X.0x
6-Core: AMD Ryzen 5 2600X
AMD Baffin [Radeon RX 460/560D / Pro
driver: amdgpu v: kernel
Display: x11 server: X.Org driver: amdgpu,ati unloaded: modesetting
OpenGL: renderer: Radeon RX 560 Series
Arch en Dual. Aucun lien publicitaire ne saurait être toléré dans la signature!
Un truc en passant:
Ce matin j'ai voulu en finir avec le dernier .pacnew qui subsistait, pas traité car il ne me sert pas: hplip.conf.pacnew.
Ouverture avec Kompare, transfert du contenu du .pacnew dans l'original et enregistrement.
A partir de là, hplip.conf.pacnew a disparu de l'interface de pacnew.chaser, alors qu'il existe toujours dans /etc/hp/.
pacnew-chaser ne s'appuie quand même pas sur le contenu des pacnew ?
Portable: Manjaro 64 KDE 5 Kernel: 4.13.12-1 Asus R510J (X550JK rebadgé vendu sans OS), Core I5-4200H, GeForce GTX 850M, 8 Go DDR3, HD 1 To, 15'5 full HD.
Par choix, pas d'UEFI, pas de swap. 3 partitions primaires: /, /home, /home/stock.
je n'ai pas encore testé le cas que tu remontes , mais cela ne m'étonne pas outre mesure
comme pacdiff, il s'appuie sur la base de donnée, puisque maintenant il est conforme à l'original c'est normal qu'il n'apparaisse plus. En gros il s'appuie sur le contenu du fichier de configuration actif (pas le pacnew).
pacnew-chaser recherche les fichiers de configuration non conformes aux désirs des développeurs avec un .pacnew mais ne cherche pas les fichiers nommés .pacnew
TODO
A voir à la sortie de l'éditeur si le fichier de config actif est identique au .pacnew (avant édition) alors supprimer le pacnew automatiquement.
J'ai testé à l'arrache : Ouverture pacnew-chaser, édition en root du pacnew de manière à ce qu'il soit strictement identique au fichier de config initiale. Enregistrement du pacnew modifié, fermeture de l'éditeur externe. Résultat : pacnew listé dans pacman-chaser et présence du pacnew dans /etc/
Conclusion, mais c'était déjà bien logique avant le test : Un pacnew peut devenir conforme à l'original suite à une modification, il reste toujours présent dans le système de fichier , à posteriori. Ne pas oublier que le pacnew est crée à l'installation du paquet concerné, si, et seulement si le fichier de conf courant est différent. Il reste ensuite dans cet état jusqu'à suppression par intervention manuelle de l'utilisateur via pacnew-chaser ou la commande rm dans le terminal.
Ce qui m'intrigue : L'absence du pacnew dans pacnew-chaser, parce que chez moi il est bien présent
letransfuge : transfert du contenu du .pacnew dans l'original et enregistrement
Tu veux dire que le .pacnew ne contenait plus rien après l’édition (fichier vide) ??
[Edit] : Je viens de faire test sur fichier pacnew vide : Même résultat que précédemment : listé par pacnew-chaser et présent dans /etc/
Testé avec panew-chaser et meld en éditeur externe.
Il faudrait reproduire à l'identique la manip de letransfuge, c'est à dire l'inverse de mon test transfert ; du pac dans le conf donc. Je le ferai dés que possible mais je n'aime pas modifier mes fichiers de config (changement de la date de modif) et je suis pratiquement certain que le résultat sera identique aux tests précédents.
Manjaro-Xfce-Compiz 64
Desktop
CPU amd-phenom-64(pci=nomsi dans grub)
CG nvidia GeForce GT 730
Ram : 4 Go
kernel : 54 branche : stable, driver GPU : Nvidia-non-libre
tu n'as pas fait l'inverse de lui ?
il faut juste transférer tout le contenu du pacnew dans le fichier actif et sauver l'actif
ps: je préfère dire "actif" que "original" car en fait l'original c'est le pacnew et l'actif c'est le fichier sans extension .pacnew
letransfuge utilise original pour l'actif
Oui, j'ai fait l'inverse mais il serait étonnant qu'en transférant du pacnew au config on n'obtienne pas exactement le même comportement, à savoir la nécessité de supprimer ce fichier à la mano.
Erwan : Il faudrait reproduire à l'identique la manip de letransfuge, c'est à dire l'inverse de mon test transfert du pac dans le conf donc. Je le ferai dés que possible mais je n'aime pas modifier mes fichiers de config (changement de la date de modif) et je suis pratiquement certain que le résultat sera identique aux tests précédents.
[Edit] : Fait, et comme prévu, pareil que les précédents tests.
Manjaro-Xfce-Compiz 64
Desktop
CPU amd-phenom-64(pci=nomsi dans grub)
CG nvidia GeForce GT 730
Ram : 4 Go
kernel : 54 branche : stable, driver GPU : Nvidia-non-libre
pour reproduire son cas, il faut trouver le bon fichier sans risque, par exemple :
modifier /etc/issue
pacman -S filesystem # qui va générer un .pacnew
pacnew-chaser
transferer le pacnew dans /etc/issue
ne pas effacer le .pacnew !
pacman -Qii filesystem # pour contrôler ce que dit pacman (MODIFIED / UNMODIFIED ?)
Le contenu est forcément bon après pacnew-chaser, mais pacman teste sans doute aussi la date, aucune idée de ce qu'il retourne... d'après ce que dit letransfuge il retournerai "UNMODIFIED" ...
EDIT pas de pacnew ! avec --debug j'ai ces lignes
debug: checking hashes for /etc/issue
debug: current: 85ca4b0f667ed147eeac275d086c4854
debug: new: d87f36842a580ff7bb91a4dee2c66507
debug: original: d87f36842a580ff7bb91a4dee2c66507
debug: action: leaving existing file in place
il compare le md5 de l’arrivant avec le md5 de celui qui devrait-être installé
Donc il ne génère un .pacnew que si le fichier conf a été modifié dans le paquet
je ferais le test avec /etc/skel/.bashrc lors de la maj stable de mon autre manjaro
papajoke a écrit : ↑il y a 5 ans
En gros il s'appuie sur le contenu du fichier de configuration actif (pas le pacnew).
Ok, là j'ai compris...
Erwan a écrit :Tu veux dire que le .pacnew ne contenait plus rien après l’édition (fichier vide) ??
Non, j'ai du mal m'expliquer...
J'ai simplement modifié le .conf à l'aide du contenu modifié du .pacnew de façon à ce qu'ils soient identiques avant et après enregistrement. Et c'était bien le cas. Le .pacnew n'est pas vide et il est dans le même état qu'à sa création.
Il existe toujours (pour l'instant) dans /etc/hp/.
Bon , tout ça m'a donné...
Portable: Manjaro 64 KDE 5 Kernel: 4.13.12-1 Asus R510J (X550JK rebadgé vendu sans OS), Core I5-4200H, GeForce GTX 850M, 8 Go DDR3, HD 1 To, 15'5 full HD.
Par choix, pas d'UEFI, pas de swap. 3 partitions primaires: /, /home, /home/stock.
Dernière modification par letransfugeil y a 5 ans, modifié au total 1 fois.
Par contre, je viens de savoir comment connaître mon DE:
$ pacnew-chaser
qt5ct: using qt5ct plugin
Tconfig.programName: pacnew-chaser
Tconfig.version: 0.9.19.1
Tconfig.ini: /etc/pacnew-chaser.ini
Tconfig.ini: /home/steph/.config/pacnew-chaser.ini
qt5ct: D-Bus global menu: no
TMainWin
not KDE :) ->xfce
Je viens de recevoir en Testing manjaro-release. Nous passons en DISTRIB_RELEASE=17.1.11
Noyau récent MANJARO x86_64 bits: 64 Xfce 4.16
ASUSTeK model: PRIME B350M-A v: Rev X.0x
6-Core: AMD Ryzen 5 2600X
AMD Baffin [Radeon RX 460/560D / Pro
driver: amdgpu v: kernel
Display: x11 server: X.Org driver: amdgpu,ati unloaded: modesetting
OpenGL: renderer: Radeon RX 560 Series
Arch en Dual. Aucun lien publicitaire ne saurait être toléré dans la signature!
Je suis dans le même cas qu'Erwan, pas de création de .pacnew
papajoke a écrit : ↑il y a 5 ans
EDIT pas de pacnew ! avec --debug j'ai ces lignes
debug: checking hashes for /etc/issue
debug: current: 85ca4b0f667ed147eeac275d086c4854
debug: new: d87f36842a580ff7bb91a4dee2c66507
debug: original: d87f36842a580ff7bb91a4dee2c66507
debug: action: leaving existing file in place
il compare le md5 de l’arrivant avec le md5 de celui qui devrait-être installé
Donc il ne génère un .pacnew que si le fichier conf a été modifié dans le paquet
je ferais le test avec /etc/skel/.bashrc lors de la maj stable de mon autre manjaro
Un debug montre effectivement la même procédure sur tous les fichiers de conf :
debug: extracting /etc/fstab.pacnew
debug: checking hashes for /etc/fstab
debug: current: bef6324f731ab5be8fcac6a9dd402157
debug: new: e33f6dfdd61978fcb3ddf1431286e05a
debug: original: e33f6dfdd61978fcb3ddf1431286e05a
debug: action: leaving existing file in place
Le .pacnew, ayant la même checksum que l'original, n'est pas extrait sur le disque.
# fichier test pour avoir un vrai .pacnew
v3
# modifier ce fichier ("v2...3") puis incrémenter pkgrel dans pkgbuild
# nano "pacnew-chaser-test.conf"
# nano "PKGBUILD"
# makepkg -fc
# puis le réinstaller
# sudo pacman -U pacnew-chaser-test-1.0.0-XXXXXXXX-any.pkg.tar.xz
# controle avec
# pacman -Qii pacnew-chaser-test
# nano "/etc/pacnew-chaser-test.conf"
pacman -Qkk pacnew-chaser-test
fichier de sauvegarde: /etc/pacnew-chaser-test.conf (Les dates de modification ne correspondent pas)
-------------------
-------------------
cela confirme ce que je disais - pour pacman le fichier est ok - donc pacman-chaser ne l'affiche pas même si un .pacnew existe
Je commence à m'en sortir doucement. Mais à la vitesse dont tu fais les mises à jour, il va faloir se remettre dans le bain tous les jours ou presque.
Mais car il y en a un lors de la dernière mise à jour, j'ai une erreur de lien symbolique à cause d'un répertoire inexistant :
Mise à jour de pacnew-chaser (0.9.19.1-1 -> 0.9.20-2)...
ln: impossible de créer le lien symbolique '/etc/pacman.d/hooks/pacnew-chaser.hook': Aucun fichier ou dossier de ce type
Erreur: pacnew-chaser: la commande n’a pas pu être exécutée correctement
Système : Manjaro XFCE LTS CPU : 6 x Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz Carte graphique : NVIDIA Corporation GP107 [GeForce GTX 1050] (rev a1) Cartes son : Audio device: Intel Corporation Cannon Lake PCH cAVS (rev 10)
Audio device: NVIDIA Corporation GP107GL High Definition Audio Controller (rev a1)