seb95 a écrit 214 commentaires

Après sauvegarde et changement des sources avec un:

mkdir /etc/zypp/repos.d/old

cp -Rv /etc/zypp/repos.d/*.repo /etc/zypp/repos.d/old

sed -e 's/42.3/15.0/g' -i *

3805 mises a jour plus tard, c'est tranquillement que je redémarre en leap 15.0.

Parfait, rien à dire, un peu long car ma connexion n'est pas au top. Merci aux développeurs et à sa communauté bien sympathique.

Non je ne pense pas, va voir sur leur forum, regarde un peu le nombre de demande d'aide depuis leurs mise a jour soit disant testé….
https://www.mageialinux-online.org/forum/index.php

Juste ce n'est pas testé et puis c'est tout c'est comme pour la version 6 qui a donné des soucis lors du passage de 5 -> 6

Peu importe le ton avec mageia on est toujours prit pour du troll, et puis c'est jamais eux, c'est plasma qui n'est pas stable, c'est le kernel qui merde, c'est l'oiseau qui passe au dessus de leurs tetes…

Excellent!

Je note tout de même un petit soucis pour moi, c'est que pour le peu que je viens d'en faire, seulement le tuto pour le moment et encore juste la première et la deuxième partie, j'ai beaucoup plus de franglais que dans le 1.12. les conseils voir même des dialogues qui étaient pourtant en français dans la version précédente sont passé en anglais.

Sinon pour les debianeux utilisant stable, vous pouvez utiliser les paquets de mon OBS:
https://download.opensuse.org/repositories/home:/seb95passionlinux/Debian_9.0/

Sinon excellent et certainement très addictif.

Vérification aussi que le paquet ne casse rien dans l'archive debian, il faut que le paquet s’insère proprement sans faire le boxon, là ou arch s'en fout de ce que j'ai compris.

Contrôle de qualité norme debian, est ce que les fichiers vont bien uniquement là où c'est convenue dans la charte… Est ce que la licence est bien présente… Bref, des contrôles internes a la distribution.

Arch peut respecter l'upstream c'est pas pour autant que c'est propre… Qui n'a jamais vu des choses s'installer dans /opt? pour quelle motifs?

Pour ce qui est des navigateur oui, pour le reste non, libreoffice est patché, le kernel aussi, firefox c'est esr,…

pour changer ou ajouter une option c'est dans le fichier rules.
https://www.debian.org/doc/manuals/developers-reference/
https://www.debian.org/devel/
https://www.debian.org/doc/debian-policy/
https://debian-facile.org/doc:mentors:retroportage

Oui oui je comprends bien que ça venait de la la "compatibilité", mais pourquoi les specs a part la partie nominatives des paquets (require, deps, ect…) ne sont que peu compatible, comment savoir ce qu'il faut changer?

Je répondrais au deux commentaire dans celui-là.

En faite il y a plusieurs manière de faire des paquets, du plus simple et automatisé à la manière bonhomme barbu avec pizzas a la main, en prenant celle que j'utilise, c'est a dire dh_make tous les fichiers du dossier debian sont fait, il ,ne reste plus qu'a les remplir, je remplis tous avec un simple editeur sauf le changelog que j'utilise dch. Apre pour fabriquer le paquet c'est debuild.

Apres, je trouve, c'est perso, que les RPM sont plus simple mais sont moins unniverselles que les DEB, je m'explique, je fais quelques paquets pour openSUSE, avec OBS (et osc), je suis souvent incapable de comprendre d'où vient mes ennuis quand j'essaye de faire un paquet pour plusieurs distributions RPM, aussi je suis souvent emmerdé en reprennant des spec de fedora ou autres pour opensuse et le contraire et vrai aussi, par exemple un paquet sous rosa m'interesse pour le faire sous fedora et opensuse et bien non ça merde… Je parle pas uniquement des buildrequire ou des deps, il suffit juste de donner le bon nom, je parle de la partie build ou install. Alors que sous debian mais peu importe en faite, je suis capable de le faire, je prends chez ubuntu des sources (je regarde quand meme ce qui se passe dedans) et puis je build pour ma debian.

Je me doute qu'il doit y avoir une methode pour que le spec soit unniversel mais comment? Là je pose une vraie question, comment faites vous de votre coté?

Par exemple actuellement, j'essaye de faire rocksndiamonds pour opensuse en 4.1, je prends le spec de fedora ou de n'importe quelle distribution RPM, et ensuite que dois-je changer dedans a part les noms des deps et des buildrequires?

@ dastious , si ça pet t'aider il y a le premier billet, qui explique un peu tous les fichiers, https://passiongnulinux.tuxfamily.org/post/construire-des-paquets-deb-pour-debian/

Dit moi ce que tu en penses:)

Oui mais il n'y a pas de verification de qualité et autre qui sont fait pour la construction de deb et de rpm. J'en avais parlé une fois avec des gars de mageia à l'époque, je disais que je ne pigeais pas que RPM et DEB soient si complexes et chiant a faire par rapport a des distributions comme arch, nutyx ou 0linux (qui etait encore plus simpliste), on m'avait dit que c'etait dû du fait que ces paquets n'avaient aucune vérification de qualité et autre.

Je ne trouverais plus la discussion car elle remonte a bien vieux (2015).

Pour la lib de webkitgtk, normalement c'est assez suivi entre les version intermédiaires, de toute façon debian le précise que seul mozilla a du support et que pour les autres c'est démerdez vous…

Bah j'ai fait des paquets suse et debian mais aussi des arch, frug, 0linux(morte), nutyx ,… je trouve pas que les debian sont particulièrement difficile, c'est vachement automatisé avec dh_make. Tu utilises quoi?
Du reste, et la je ne parle que d'exportation de paquets, c'est plus simple de prendre un paquet source de deb comme ubuntu pour faire un paquet debian et vise-versa que des RPM, fedora pour opensuse et (vise versa) dont je suis toujours à la recherche de ce qui va merder.

Maintenant oui, il y a milles et une façons de faire des deb, du plus emmerdant et moins automatisé au plus automatisé.

Et pourtant ce n'est pas stupide, et oui debian maintient comme d'autres distributions des logiciels sur le long terme et redescend des correctifs ou font eux même des correctifs. Ce que arch ne fait pas du à son système de sortie(rolling). Par contre dire que sous debian on est dans la merde si l'upstream c'est du n'importe quoi, que dire alors de centos, redhat, suse?

La partie du bureau à la ramasse sous debian , oui je l'entends tous les jours et ça n'empêche pas les debianeux de l'utiliser aussi la stable pour leur desktops.

J'aimerais bien connaître ou debian est une grosse bouse au niveau de la sécurité ? Par contre arch faire de la maintenance sur 5 ans j'aimerais bien voir ça, il n'y a personne et surtout personne veux se faire chier et préfère juste confier la sécurité sur des paquets mis à jour continuellement.

Pour la difficulté de faire un paquet debian, tout dépend des outils utilisés, si on utilise les outils les plus évolué c'est 80% du travail fait automatiquement, je viens plus haut dans ce journal démontrer que le taf a été fait à 100% je n'avais rien à faire pour faire mon nouveau paquet à par lancer deux commandes.

Maintenant à partir de zéro le paquet debian fait peur car il n'y a pas un fichier à remplir mais plusieurs, c'est juste impressionnant mais une grosse partie est faite en automatique, mais c'est comme tout faut en faire quelques un pour être à l'aise. Par exemple je ne suis pas bien à l'aise avec les RPM, il y a toujours un trucs qui merde si on reprends un spec d'une autre distribution, et je m'en sors donc mieux avec le deb.

Ça merde pas mal le markdown et comme a mon habitude je valide ne voyant rien de mal au début… Sauf qu'il y a beaucoup de différences, des placement qui diffère, du code qui n'est pas en code, …

désolé pour le raté…

Bon du coup le billet est par là:
https://passiongnulinux.tuxfamily.org/post/construire-des-paquets-deb-pour-debian-suite/

Oui promit, il ne bouge plus, je reste sur hugo simple et efficace, pas de maintenance, je n'en bouge plus :)

Disqus est clairement pas cool, mais c'est soit je trouve un truc simple et libre/propre ce que je trouve pas, soit je met disqus ( pas libre, ça pue mais ça gere tres bien le spam) soit j'enleve les commentaires;) Pour une question de simplicité et d'aller vite, j'ai choisi de garder un minimum de commentaire et donc disqus;)

Merci pour la vidéo. Je n'ai pas encore osé utiliser OBS et OSC sur Debian, j'ai bien sur fais un paquet depuis ma debian avec debuild puis envoyé la origine.tar, le debian.tar et le fichier.dsc et ça la fais sans soucis.
OSC sous debian c'est complet?

oups, merci Antoine

Quid des correctifs liés à Spectre ? C'est un backport maison ?

C'est corrigé depuis pas mal de temps
https://news.opensuse.org/2018/01/26/opensuse-meltdown-spectre-update-26-jan-2018/

http://franck-ridel.fr/de-fedora-a-opensuse-the-gros-switch/

Bonne question, j'ai posé la meme:)
Voici la réponse:
https://www.alionet.org/content.php?813-Comment-sont-choisies-les-versions-du-kernel-de-Leap

La prochaine version d'openSUSE Leap, numérotée 15, pointe son nez et on sait d'ores et déjà qu'elle bénéficiera du noyau Linux en version 4.12.
Cela pourrait en étonner plus d'un et on serait en droit de se demander pourquoi un tel choix alors que la version courante du noyau est 4.15 ou si, au court de sa vie, le noyau de Leap 15 pourra être mis à jour afin de ne pas rester avec un noyau jugé trop ancien.

Cette question a été posée sur la liste de diffusion opensuse-factory et un des participants très informé à bien voulu prendre le temps de donner une réponse claire et complète qu'il paraît important de retransmettre. Le texte qui suit en est donc une traduction et une adaptation au format « article » libres.

Pourquoi Leap 15 aura le noyau 4.12 au lieu de la version 4.14 (ou ultérieure) ? (par Peter Linnell)

Il faut tout d'abord rappeler que la distribution openSUSE Leap bénéficie d'une base de code partagée avec la version professionnelle SLE (Suse Linux Enterprise), base dont le noyau fait partie. À cet égard, il faut beaucoup de temps pour que le noyau obtienne les certifications requises pour fonctionner sur les matériels des clients de Suse et avec les logiciels d'autres éditeurs professionnels. Toutes les étapes permettant une telle certification pour le noyau 4.12 auraient dû être retardées ou bien recommencées pour la version 4.14 si celle-ci avait été choisie en finalité.
Le travail à fournir afin d'obtenir une telle certification est colossal et coûteux, il nécessite la mobilisation de nombreux ingénieurs et requiert d'avoir à disposition les différents matériels pour lesquels la distribution doit être certifiée.

L'auteur de la réponse initiale rapporte l'exemple du processus de certification d'un serveur type « lame » et d'une armoire de stockage. Il a fallu pour cela mobiliser 3 ingénieurs durant plusieurs jours, assurer le déplacement au travers des États-Unis de 2 experts SUSE (dont l'auteur) pour un total estimé à plus de 10 000 $. Le tout pour certifier un seul type de matériel !

Les membres de la communauté openSUSE ne sont sûrement pas tous conscients du genre de matériel pour lequel est certifiée la SLE (SUSE Linux Enterprise) (ndt: et donc le noyau de la Leap) mais il s'en trouve parmi eux de très exotiques et très chers.
On peut citer deux exemples :

1. Les serveurs SAP HANA qui tournent quasi exclusivement sous SLES (SUSE Linux Enterprise Server). Une image système de 32 To peut absorber jusqu'à 5 ou 6 fois ce volume de données compressées et les contenir en mémoire. Nous parlons là de 150 à 180 To de données disponibles en RAM afin de réaliser des analyses en temps réel !
   Pratiquer des tests sur ce genre de monstres nécessite d'une part des semaines d’ingénierie et d'autre part que le fabriquant mette à disposition une machine de plusieurs millions de dollars.
   https://www.hpe.com/us/en/solutions/sap-hana.html

2. Les systèmes SGI, une entreprise rachetée par HPE. Il s'agît de systèmes NUMA (« non uniform memory architecture » ou architecture mémoire non uniforme) pouvant théoriquement gérer jusqu'à 64 To de RAM avec un seul noyau Linux.
   https://www.hpcwire.com/2016/05/11/t...life-sciences/

En ce qui concerne les logiciels, certaines piles logicielles éditées par les fabricants peuvent prendre des semaines pour être certifiées. Les fabricants eux-mêmes peuvent réaliser des tests de résistance ou des contrôles qualité afin de s'assurer que tout est conforme. Après tout, les éditeurs de logiciels fournissent un certain niveau de garantie à leurs clients en ce qui concerne la compatibilité et la stabilité qu'ils se doivent de maintenir. Un problème dans leurs logiciels pourrait entraîner un manque à gagner considérable pour leurs clients.

Donc, du point de vue de l'entreprise, la décision que telle version du noyau sera utilisée met en branle une machinerie complexe, requérant une grande coordination, en interne mais aussi avec les clients et partenaires. Ce genre de décision n'est donc pas pris à la légère.

En tant que membres de la communauté openSUSE, nous avons donc de la chance de bénéficier d'une telle ingénierie. Ce sont littéralement des millions de dollars d'investissement qui, non seulement sont mis à disposition dans Leap, mais qui démontre bien la volonté affirmée de SUSE de voir openSUSE réussir et de l'intérêt que l'entreprise porte à notre communauté.

Pour conclure, il faut rappeler, si besoin, que le noyau, bien qu'en version 4.12 bénéficiera des rétro-portages (« backports ») tout au long de sa durée de vie en vue d'apporter des correctifs et d'améliorer la prise en charge matérielle et logicielle.

Ah, j'ai testé l'image en durs et aussi le live… Pas fait de virtualisation.

Quelle version? Actuellement c'est la 191 mais mon image date de mars et est totalement opérationnel, mais les derniere date d'y a à peine 2jours, peut etre une mauvaise serie?

http://download.opensuse.org/distribution/leap/15.0/iso/openSUSE-Leap-15.0-DVD-x86_64-Current.iso.torrent

Mais bien sur, en faite la leap actuelle est basé sur SLES 12.3 et SUSE ne pouvant pas avoir deux même numéro identique pour leurs distributions pro et communautaire et surtout vu que openSUSE était déjà en version 13.X et avait donc dépassé la série des 12.x, il était peu probable de faire machine arrière et remettre un numéro de série ayant déjà été utilisé, donc il a été décidé de faire num de SLES+30=num de leap, ce qui faisait 42.X et faisait référence à la 1er version de SUSE linux qui était 4.2 et aussi comme un clin d'œil humoristique au guide de la
galaxie. Au final, la série 42 n'était que la série 14 déguisée ^{^}

https://lists.opensuse.org/opensuse-announce/2017-04/msg00000.html

Maintenant SLES va sauter de 12 à 15 pour se calquer sur openSUSE:

SUSE's decision to skip SLE 13 and 14 gave us a perfect opportunity to
sync up with SLE versions like we always wanted to originally with
Leap. It's an opportunity we will not be able to take so easily a few
years from now if we continued with Leaps current versioning.

Voila, j’espère avoir été clair ;)

Très bonne version, GNOME est devenu un bien beau bureau, seulement voila, je passe carrément du simple au double pour la consommation. Je commence directement avec 1 go de ressource et aucune application tournant, mes processeurs tournent peu ça encore c'est bien, par contre pourquoi autant de RAM utilisé des le début?

J'avais déjà remarqué l'appétit avec la 3.26 et c'est encore plus marquant avec cette 3.28.

Je vais etre radicale, mais il me semble que les kernels linux récents ne supportaient plus le i386? Je sais plus si c'est ici ou autre part mais maintenant le kernel supporte le 32bits a partir du i586, si je me trompe pas. Alors c'est simple mais la première machine que j'ai n'est simplement pas du i586. Ensuite même avec du fluxbox et autre tout léger, le démarrage est tout de même long. Par exemple ma Debian ne fonctionne pas dessus, elle échoue a chaque fois, je dois garder une lenny pour y être installé.

Voila, puis après il y a le coté plus ou moins complet, avec fluxbox je devrais sélectionner paquets après paquets pour mes besoin, au pif une application calculette, avec haiku j'ai déjà tout ça et tout prêt. Et puis changer un peu ça fait du bien :)

En tout cas merci de vos réponses.
@ pulkomandy ,

La beta n'est pas encore disponible, mais sur http://download.haiku-os.org tu peux trouver des "nightly builds" qui s'en rapprochent et que je recommande d'utiliser. En particulier, le gestionnaire de paquets est disponible ce qui simplifie pas mal de choses.

Je l'ai fais, mis sur une clé, et installé pour le moment sur une petite clé, c'est super, a tel point que je suis entièrement convaincu d'avoir trouvé l'OS dont j'ai besoin et puis quelle rapidité!!! Ça nous change de nos linux qui plus ça va plus il devient lourd, je parle surtout des deux mastodontes kde et gnome.

Il n'y a plus tellement de travail à faire sur le code, les nightlies sont plutôt stable (même si ce n'est jamais parfait). Le gros du travail sur la beta est plutôt sur la mise en place de l'infrastructure pour construire et distribuer les paquets, chose qu'on a pas trop l'habitude de faire pour le moment.

Alors je certifie que c'est vraiment stable et surtout rapide, c'est un peu bizarre puisque jamais utilisé sauf rarement pour essayer a une ou deux reprises, mais c'est très intéressant, bon je me vois pas mettre haiku sur mon pc principal car j'aime le confort de kde, gnome (actuellement) ou/et surtout xfce mais sur un second pc utilisé tout aussi souvent c'est vraiment top…

Vraiment encore une fois, je sais pas si j'aurais les capacités a donner de mon temps, mais votre projet m'interesse au plus haut point.

@ freejeff;

Je ne connais rien à Haiku mais j'ai récemment redonné vie à un netbook d'il y a plus de 10 ans avec puppy linux et le résultat est bluffant. Le choix d'application est fait pour que cela soit utilisable sur de très vielles machines. Tu as de plus un très large éventail d'applications installable. Tu as pleins de version avec comme base slackware ou ubuntu.

Effectivement, je connais un peu pupy ou sa version française toutoulinux (je sais meme plus si c'est ça)

Je pense que tu pourras facilement refaire vivre ton PC avec ça. De plus tu peux tester en liveCD.
Oui il est facilement capable, un peu comme slitaz mais en meme temps ça fait du bien d'essayer des chose autre que du linux;)

Je pense que le test en machine virtuelle ne sert pas à grand chose. Les problème que tu risque d'avoir serait la compatibilité de ta carte graphique avec les noyaux modernes.
Je suis d'accord, le virtuel c'est pour donner une idée avant de l'essayer en dur, ce que je fais tres vite apres ;)

C'est super en tout cas de ne pas abandonner de vieux PCs !
Ça c'est sur, je n'aime pas le gaspillage, j'avais encore peu une grosse tv qui faisait précisément 45 kg, je l'ai gardé jusqu’à ce qu'elle me lâche, 13 ans de vie on va pas se plaindre. Là les PC dont je parle fonctionnent encore tres bien, alors le plus vieux n'est pas capable de me faire démarrer firefox en un temps record mais midori me permet de voir les sites que je visite souvent, pour l'autre il tourne sur une nutyx xfce mais j'ai bien peur que tôt ou tard le 32 bits dans linux soit de moins en moins toléré ( c'est un i586).

Amicalement