<coyotus> comment tu fais pour exporter tes modif sur git pour avoir tes sources à jours en temps réel ?
<starsheep> git push ? ^^
<coyotus> depuis le dossier de build ou l'env de test ?
<arpinux> même pas git perso ... je fonctionne avec un cloud openmailbox.
<arpinux> mais pour la synchro
<arpinux> je fonctionne au cloud à la main
<arpinux> entre la machine test et la machine de build
<arpinux> oui
<arpinux> c'est automatisable
<arpinux> genre git push depuis ta machine de test et git pull depuis ton dossier de build
<arpinux> mais ça impose l'installation de git sur la machine test
<arpinux> alors que justement
<arpinux> la machine test doit rester la plus fidèle possible à l'installation par défaut du user
<arpinux> pour ça que j'utilise un cloud
<arpinux> par exemple
<arpinux> juste avant le build
<arpinux> j'archive sur la machine test mon ~/.mozilla , ~/.config ...
<arpinux> j'upload sur cloud
<arpinux> je récupère sur la machine de build
<arpinux> je mets à jour les dossiers dans le build et hop
<arpinux> ça laisse le système de teste vierge
<arpinux> car c'est ça le piège
<starsheep> Tu fonctionnes en 3 temps alors ?
<arpinux> quand on geek souvent, on se dit que modifier la bonne ligne suffit, mais comme tu l'as dit tout à l'heure, une modification de syntaxe peut aussi intervenir sans ton "consentement" et donc, tu ne le reportera pas dans le build, sauf à synchroniser les dossiers
<starsheep> Tu build un premier coup, tu balances sur la machine de test, tu fais ta config et tu balance le $HOME pour créer le skel et tu rebuild ?
<arpinux> en gros starsheep oui :)
<starsheep> heeeeeeeein
<starsheep> ah ben je viens de comprendre un truc
<starsheep> et avec une VM et un partage de fichier ça ne peut pas être plus simple ?
<arpinux> mais im ne faut pas non plus tout prendre dans le home de ton test
<starsheep> alors pour le skel je comprends. Mais /usr/share il n'est pas modifié par les paquets lui ?
<arpinux> si on peut
<arpinux> mais sans ajouter de programmes qui seront appelés plus tard
<arpinux> par exemple
<arpinux> si tu veux coller ta version de conky dans le build
<arpinux> tu peux
<arpinux> - forker le paquet et l'appeler depuis la liste des paquets
<arpinux> - forker ton paquet et l'ajouter en dur dans le build
<arpinux> - forker le binaire et l'ajouter à la main
<arpinux> Mais
<arpinux> dans le cas 1, il faudra configurer apt pour lui indiquer par pinning de préférer ton conky à celui d debian lors de la prochaine mise à jour
<arpinux> dans le cas 2, idem, mais en plus, tu ne pourras pas mettre ton conky à jour
<arpinux> dans le cas 3, ton conky sera écrasé dès le build par l'installation du 'vrai' conky
<arpinux> donc tu dois forker + renommer
<arpinux> ou alors
<arpinux> forker + placer ailleurs
<starsheep> ok
<arpinux> genre .usr/local/bin
<starsheep> aaaaah ok
<arpinux> dans le cas de DFLinux ou nos autres projets, le soucis ne se pose pas
<starsheep> c'est pour ça que dans kissos tu as un /usr/local/share
<arpinux> carnos programmes sont des ajouts et non des forks
<starsheep> pour dwm-kissed
<arpinux> oui starsheep, et aussi pour respecter l'architecture de base : ajout externe > local
<arpinux> et donc un autre aspect pratique que je souhaitais souligner à propos de live-build,c'est la séparation binary/chroot visible dans plusieurs dossiers/fichiers.
<arpinux> live-build permet de séparer les applications installées dans le live de celles effectivement intégrées dans la distribution finale
<starsheep> binary c'est pour le live et chroot pour l'installation ?
<arpinux> donc le live 2 en 1 :)
<arpinux> le principe est d'intégrer des programmes qui seront présent dans le live, mais pas dans la session installée et inversement :)
<arpinux> ainsi, vous pouvez avoir sur un même cd, gparted disponible en live pour vérifier vos disques, mais pas dans la version installée
<arpinux> plusieurs avantages : la disponibilité dans le live de nombreux programmes sans pour autant alourdir le système installé
<arpinux> l'installation de nombreux programmes dans le système installé sans alourdir lechargement ni les menus du live
<arpinux> l'équilibre est à trouver selon l'objectif du live
<arpinux> mais vous voyez de suite le panel des possibilités :)
<starsheep> yep
<arpinux> l’extrême étant de faire un live qui n'a rien à voir avec le système installé au final
<arpinux> et c'est possible de façon "transparente"
<arpinux> cad sans que le user du live puisse le voir
<starsheep> Il n'y a pas moyen de faire un truc commun aux deux sans faire doublon dans les sources ?
<arpinux> un système live jessie stable pour tourner tranquille, mais qui renvoi à l'installation d'un sid
<arpinux> car les binary/chroot
<arpinux> sont des options disponibles aussi pour les miroirs consultés lors du build
<arpinux> donc live-build peut appeler des paquets de différents branches de debian pour le live indépendamment des paquets du système final
<kyodev> genre tu appâtes le chaland et crac! sid :o)
<arpinux> yes ! :D
<arpinux> sans aller jusque là, ça a le mérite de pouvoir éviter la surcharge du live en en supprimant toutes les applications non-essentielles par exemple
<arpinux> un live-ultra-light installant un système complet :)
<arpinux> l'inverse est possible aussi. un live ultra-complet pour montrer de quoi est capable debian, mais plusieurs formats d'installation
<arpinux> car oui
<arpinux> on peut aussi installer plusieurs système différents depuis le même live
<arpinux> en dehors de la distinction binary/chroot
<arpinux> oui
<arpinux> ça en fait des possibilités :)
<arpinux> alors pour ceux que ça branche, voilà le principe
<arpinux> vous trouverez dans les sources de DFLinux https://git.framasoft.org/dflinux/DFiso le dossier /config/includes.binary/isolinux
<arpinux> c'est la config du menu syslinux au boot du live
<arpinux> le fichier install.cfg liste les entrées de menu pour l'installation. il indique lefichier preseed de préconfiguration à utiliser, on en a parlé au début.
<arpinux> il suffit de coller plusieurs entrées, avec un appel à des preseed différents :)
<arpinux> on peut coller une liste de paquets dans le preseed, donc....
<arpinux> potentiellement une autre distro
<arpinux> et autant de sitro que d'entrées de menu syslinux
<arpinux> donc les hooks sont des scripts qui s'exécutent dans le chroot juste avant de le quitter et de le compresser en squashfs
<arpinux> même moment que interractive
<arpinux> mais en automatique
<arpinux> c'est pour le fignolage
<arpinux> :)
<starsheep> ok !
<arpinux> on peut potentiellement faire tout ce qu'on veut
<arpinux> pas de limite
<starsheep> Je les oublie toujours ceux là
<arpinux> openbar dans le chroot
<roodinux> pourquoi ils ont des chiffres les hooks ? Si on ajoute celui que tu proposes dans le tutto on le nomme avec une valeur particulière ?
<arpinux> l'ordre d'exécution
<arpinux> ils s'exécutent dans l'ordre, tout simplement
<arpinux> donc pratique si une action en demande un autre :)
<roodinux> celui pour prendre en compte les ‘proposed-updates’ tu le nomme comment ?
<arpinux> sans numéro particulier dans les sources car il peut se lancer n'importe quand
<arpinux> proposed-update.chroot
<arpinux> un autre fichier à tout faire
<arpinux> c'est une option du fichier preseed dont on a déjà parlé
<arpinux> -late-command
<arpinux> c'est une option passée à l'installeur debian
<arpinux> et qui permet de lancer des commandes sur le système fraîchement installé avant le reboot
<arpinux> c'est la dernière chance de modifier le système avant que l'utilisateur prenne la main dessus
<arpinux> dans les sources et le tuto support, il ne fait pas grand chose hormis fixer la date d'installation et virer 3 paquets inutiles au cas ou l'installeur ne l'ai pas fait
<starsheep> après on ne peut même plus balancer de virus
<starsheep> pas drôle
<arpinux> depuis les dépôts externe, si, mais c'est mal
<arpinux> :)
<starsheep> :)
<arpinux> faut voir le process de build en 3 temps
<arpinux> installation du système de base dans un chroot
<arpinux> copie du chroot modifié (le includes.chroot) dans le chrrot de build
<arpinux> compression du chroot et build du live
<starsheep> le système de base c'est donc Debian dans ce cas
<arpinux> le hook se fait juste avant la fin du 2
<arpinux> oui starsheep , plus les paquet listés dans le build
<arpinux> ensuite viennent les modifs du includes
<arpinux> ensuite les hooks système
<arpinux> ensuite les hooks perso
<arpinux> puis la compression en squasjfs
<arpinux> squashfs
<starsheep> et enfin les -late-command
<arpinux> non starsheep
<arpinux> les late-command, c'est à l'installation
<arpinux> les hooks ,c'est lors du build
<arpinux> oui, il y a vraiment énormément de façon de modifier son live, même après le build
<arpinux> pour la liste complète des options acceptés, un man lb config renseignera
<arpinux> mais le but de ce soir est vraiment d'en faire le minimum pour un résultat optimal
<arpinux> donc dans les options indiquées dans auto/config, on remarque la ligne "architecture" qui permet de construire un live avec une arch différente de celle du système hôte
<arpinux> notez qu'il n'es pas possible de build une amd64 depuis un i386 mais l'inverse, oui
<arpinux> on va déjà se concentrer sur le processus global pas à pas et ne pas détailler chaque option de suite sinon ce sera sans fin et surtout illisible pour quelqu'un qui aimerait suivre le tuto
<arpinux> comme je disais, la liste complète des options est dispo dans le man, mais il n'est pas totalement à jour
<arpinux> donc pour vérifier celles que vous voudriez modifier dans les sources de ce soir,
<arpinux> on peut se reporter aux fameux "test à vide" effectué hier ou simplement se contenter de celui que je fournis et qui vous permettra de build sereinement sans trop vous poser de question au début :)
<arpinux> le plus important reste la personnalisation
<arpinux> donc la suite de la personnalisation réside dans les applications à installer
<arpinux> ce soir, on va faire simple, on va coller les mêmes apps dans le live et dans le système final
<arpinux> mais il est possible de séparer les paquets pour avoir des applications en plus/moins dans le live et le système installé, on y reviendra au final
<arpinux> donc la liste des paquets se trouve dans le dossier config/package-lists/
<arpinux> qui arrive :)
<arpinux> alors effectivement, dans la liste que je vais poster, on pourrait encore simplifier
<arpinux> et vous pourrez d'ailleurs le faire
<arpinux> je push ... j'arrive :)
<arpinux> vous pouvez pull depuis les sources
<arpinux> ou visitez les commits https://git.framasoft.org/arpinux/dfl-apprentissage/commits/master
<arpinux> la bannière de l'installeur graphique :)
<arpinux> et donc, avant de taper dans les trucs longs et embêtant
<arpinux> un petit plaisir de sucto
<arpinux> la bannière
<arpinux> le truc qui va s'afficher en haut pendant l'installation
<arpinux> et qui dire
<arpinux> dira
<arpinux> "tu installe ma distro" :D
<arpinux> un peu d'ego ne fait pas de mal si il ne fait pas d'ombre à l'autre :)
<arpinux> c'est dans le dossier config/includes.installer/usr/share/grahics/
<arpinux> qui n'est pas encore là :)
<arpinux> vous pouvez git pull ou visiter les commits :)
<arpinux> oui, je sais, c'est futile
<arpinux> mais ça rassure aussi l'utilisateur de savoir que le builder s'est un peu fait chier à personnaliser son truc et n'a pas juste balancé 2 walls et 3 applis :)
<arpinux> pour le personnaliser, vous pouvez changer les labels des entrées , le fond et même en rajouter
<arpinux> par exemple
<arpinux> lister plusieurs entrées avec différentes langues activées par défaut
<arpinux> car les options passées à syslinux sont comme les options de grub
<arpinux> on va voir de suite un custo simple
<arpinux> ça se passe dans /config/includes.binary/isolinux/
<arpinux> qui arrive :)
<arpinux> vous pouvez git pull ou visitez les commits https://git.framasoft.org/arpinux/dfl-apprentissage/commits/master
<arpinux> le nouveau dossier intègre un menu pour le live et un fond d'écran
<arpinux> mais vous pouvez aussi personnaliser le label d'installation, le titre principal etc
<arpinux> vous aurez des exemples plus complet sur DFLinux
<arpinux> donc le fichier live.cfg
<arpinux> vous pouvez voir que ce fichier contient le label "tester debian" en premier
<arpinux> avec un ^
<arpinux> c'est pour indiquer la touche d'accès rapide au clavier
<arpinux> le raccourcis quoi ..
<arpinux> la dernière ligne de chaque section indique les options passées au kernel
<arpinux> append boot = ....
<arpinux> c'est là que vous pouvez spécifier la langue du live
<arpinux> le fichier install.cfg n'est pas dans ces sources car on ne le personnalise pas, il sera ajouté par live-build et donc, on aura bien une entrée 'install' dans le menu final :)
<kyodev> ligne e: option, c: console
<kyodev> c'est qui qui fait?
<arpinux> un fichier qui se nomme stdmenu.cfg
<arpinux> qui n'est pas présent dans ces sources mais dans celles de DFLinux
<arpinux> on n'y touche pas ce soir, donc il n'est pas dans ces sources
<arpinux> donc je termine sur la custo du menu
<arpinux> pour les couleurs, la disposition etc, franchement, c'est la galère car c'est tout en code de taré
<arpinux> (terme technique assumé)
<arpinux> donc faites simple, ce sera mieux :)
<arpinux> et puis, ce n'est pas non plus l plus important, le tout étant d'avoir la bonne langue au démarrage :)
<arpinux> donc si vous êtes partant, on peut lb build :D
<arpinux> depuis les sources, vous pouvez envoyer la commande
<arpinux> sudo lb build
<arpinux> plus sûr
<arpinux> donc voilà, avec ces sources https://git.framasoft.org/arpinux/dfl-apprentissage , vous avez une armature pour un live simple sur xfce, que vous pouvez agrémenter avec le tuto live-build et faire votre distro
<arpinux> j'espère avoir été clair et simple
<arpinux> et que vous avez vu le processus en global
<PengouinBSD> enfin, non, mais bon, t'as compris :D
<arpinux> oui :)
<arpinux> alors pour construire un live sid ... peut être passer par un live ç vide stretch, mais avec un hook, un seul, pour exécuter une dist-upgrade du chroot vers sid avant la fin du chroot :)
<arpinux> donc un installeur stretch, mais qui copie un système sid
<arpinux> parce que normalement, pour installer une sid, on prend la netinstall testing, on passe en mode expert install et on demande à choper la version unstable dans les options
<arpinux> mais il n'y a pas de live sid proprement dit
<lagout> sid seul n est pas utilisable en tant que tel
<lagout> y à pas asser de paquet
<arpinux> mais c'est marrant que live-build accepte de build en sid quand même
<arpinux> enfin "marrant" ....
<arpinux> une autre idée
<arpinux> choper ta config, mais en collant "stretch"
<arpinux> et en plus
<arpinux> dans config/archives
<arpinux> on rajoute la ligne des dépôts sid
<arpinux> :)
<arpinux> donc juste remplace "sid" par "stretch" dans auto/config
<arpinux> et ajouter dans config/archives
<arpinux> sid.list.chroot et sid.list.binary
<arpinux> avec deb http://ftp.fr.debian.org/debian/ unstable main contrib non-free
<lagout> PengouinBSD: c est ça qui est drole
<arpinux> ah si
<arpinux> j'ai changé "netinst" par "live" pour l'installeur
<PengouinBSD> arpinux, si je ne me trompe, ça va faire quand même une install qui dure 2 * + de temps, non ?
<arpinux> cad ? 2*+ de temps ?
<PengouinBSD> beh, oui, y'a la phase d'install stretch puis sid
<arpinux> non
<arpinux> pas comme j'ai fait
<arpinux> pas de hook
<arpinux> en ajoutant la ligne sid dans archives
<arpinux> je dis à live-build de le prendre en compte directement dans le build
<PengouinBSD> pourtant il récupère bien tous les packages en interrogeant les dépôts Sid !
<arpinux> mais tout en précisant d'utiliser le système de base stretch (donc tous les paquets dispo)
<arpinux> l'option --distribution "stretch" indique à live-build de tout mettre en place avec les outils stretch
<arpinux> la ligne dans archives indique qu'il peut choper aussi des paquets de sid
<arpinux> ce n'est pas pareil que de dire directement à l'installeur de bosser sur sid
<arpinux> là il taf que stretch
<arpinux> et si il peut
<arpinux> il chope du sid
<arpinux> théoriquement, ça devrait marcher :SD
<arpinux> :D
<arpinux> il build là
<arpinux> il va bien chercher l'installeur chez stretch
<arpinux> build stretch/sid terminé
<arpinux> live fonctionnel
<arpinux> je tente l'install ??
<arpinux> install lancée ....
<arpinux> pas de module noyau ....
<arpinux> ça commence mal....
<arpinux> aucuen carte ethernet trouvée ....
<arpinux> bon bah non .... abort install
<arpinux> haha
<arpinux> à jouer avec stretch/sid alors que debian est prévu comme 'stable' ... jte jure ...
<PengouinBSD> hihihihihihi
* PengouinBSD "love exciting way :p!"
<arpinux> ça t'amuse de me faire build nawak hein ???!!!
<arpinux> :D
<PengouinBSD> YESSS!
<PengouinBSD> XD
<arpinux> alors pourquoi ça ne fonctionne pas
<arpinux> si on utilise distribution "sid", il manque des paquets