Journal Les joies d'une distribution en Rolling Release.

Posté par  .
Étiquettes :
5
26
nov.
2010
Cher journal,
En ce froid vendredi, un froid si rude à engourdir tous les trolls du pays, j’ai eu la joie de constater la mise à jour du kernel 2.6.36 sur ma distro Archlinux fraîchement installée depuis quelques semaines.
Super, me dis-je, enfin une distribution qui propose ce noyal en version stable, pas comme sur Debian où il faut aller le piocher dans experimental, donc, tout contant, je laisse se faire tranquillement la mise à jour des paquets en savourant par avance l’extase du prochain reboot.
Chouette, l’installation vient de se terminer, quelques secondes plus tard, la commande uname me retourne un joli 2.6.36.
Et patatras, mais comme c’est étrange, la connexion par wifi ne fonctionne plus, quelle horreur. Un ch’tit tour dans les logs, hmmm, pas fameux, des IOCTL eror sur le module RT2860sta sur les 20 dernières lignes, dépité, je rebranche le bon vieux câble Ethernet des familles et cherche la solution dans les divers forums.
En attendant de trouver une solution, je me demande si le choix d’Ubuntu de passer en mode Rolling Release est une bonne idée, je me demande bien comment un utilisateur standard va bien pouvoir s’en sortir sans tripatouiller la configuration en ligne de commandes.
Et vous, que pensez-vous des implications du mode Rolling Release pour monsieur tout le monde ? Linux est-il prêt pour le Desktop ?

  • # Je compatis

    Posté par  . Évalué à 3.

    De mon côté, suite à la mise à jour de Xorg, du noyal et du pilote proprio nvidia je ne peux pas aller plus loin que kdm. Je n'ai plus que ssh pour pleurer… euh accéder à ma machine ! D'après les logs, Networkmanager n'a pas l'air très content non plus.

    • [^] # Re: Je compatis

      Posté par  (site web personnel) . Évalué à 10.

      C'est marrant le contraste avec tous les messages comme quoi Archlinux est la solution parfaite à tout.

      • [^] # Re: Je compatis

        Posté par  . Évalué à 2.

        Honnêtement je pense qu’il n’y a pas de solutions vraiment parfaites, je voulais simplement faire un petit retour d’expérience ayant souvent entendu des louanges de cette distribution.

      • [^] # Re: Je compatis

        Posté par  (site web personnel) . Évalué à 2.

        Mwai, enfin je maintiens trois Arch (parent, ex, soeur) via ssh sans aucun problème...

        Et la semaine dernière, celle de ma soeur s'est mangé une mise à jour de plus d'un an sans soucis...

        Après, rien n'est parfait, c'est sur...

      • [^] # Re: Je compatis

        Posté par  . Évalué à 4.

        la "rolling release", ce n'est pas la solution parfaite à tout.

        Ça vise juste à pallier le plus gros défaut de linux : d'avoir à subir une vieille version d'un logiciel utilisé tous les jours (firefox, openoffice, gimp, inkscape...), dénommé "logiciel pour l'utilisateur final", tout ça parce que ce logiciel utilisateur dépend de python, pango, gtk, perl, libc et compagnie ("logiciels systèmes"), alors que sous windows il suffit juste d'installer un .exe pour avoir tout ce qu'il faut et un logiciel à jour (et libre, qui plus est, vu que cela concerne les mêmes logiciels)

        Dans la plupart des cas, tout mettre à jour se passe plutôt bien (même si c'est gavant d'avoir à télécharger autant de trucs juste pour mettre à jour des docs et des logiciels que l'on n'utilise qu'indirectement), parfois ça peut casser.

        Mais quel intérêt d'avoir le dernier noyau ou le dernier pilote graphique quand celui-ci fonctionne déjà correctement ?

        À part ça, Arch ce n'est pas qu'un aspect rolling release, c'est également un système de création de paquets que je trouve inégalé au niveau facilité et practicité, ainsi que le côté KISS de l'init BSD (un seul fichier pour gérer tout ça)

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: Je compatis

      Posté par  . Évalué à 1.

      J'ai fait plus fort !

      J'ai oublié de monter /boot avant la mise à jour du paquet kernel26.

      Après 10 minutes de "gniiééé", parce que ça démarrait quand même avec quelques modules en moins (hum), donc plus d'usb, Xorg se lance mais plus d'entrée clavier/souris, etc.

      Je fais uname -a, je vois 2.6.35 et je comprends.

      Je regarde mon /boot, censé être vide car jamais monté, et là, le drâme. Je supprime le contenu de /boot, veut remonter /boot, mais, mais, plus de module ext2 !

      Bon, passage sur un live cd, chroot en règle avec mon /boot enfin monté, et bind de dev, sys, proc, et hop un pacman -S kernel26.

      Je redémarre péniblement, ça refonctionne mais :

      ....

      Les pilotes catalyst, ils sont totalement non supportés par archlinux !
      Et là, découverte du paquet catalyst-hooks, je vous passe les détails mais pratique pour les mises à jour noyau.

      Quelques bidouilles plus tard et en occupant 1h de cours et 30 min de pause midi, je peux enfin dire à la face du monde, fier de moi :

      $ uname -r
      2.6.36-ARCH

      Au passage, merci wicd pour ce magnifique client curses. :)

      • [^] # Re: Je compatis

        Posté par  . Évalué à 2.

        c'est rigolo, j'ai eu presque le même pb ce matin, je tourne sous arch depuis quelque petits mois sans pb, je fais mes update tous les jours en me demandant quand je vais réussir à casser mon installation et retourner sous debian, j'ai bien cru que ça y était, mais non :-)

        mon /boot n'était pas monté à cause de mauvaises options (s'appliquant à de l'ext4 sur ssd alors que le boot est en ext2) dans le fstab et je ne m'en étais pas aperçu jusqu'à cet upgrade de noyau...

        ça fait plaisir de constater que je ne suis pas le seul à lire les petites lignes, il suffisait pourtant de lire l'avertissement du script d'installation : "il apparaît que votre /boot est dans une partitions séparée qui n'est pas montée, ça n'est sans doute pas ce que vous souhaitez..." (traduction approximative)
        et c'est comme ça qu'on se retrouve avec un noyau installé avec SUCCESS....dans le mauvais répertoire (jamais lancé par grub)
        bon, ça aura été l'occasion d'apprendre quelques trucs utiles, donc 1h pas complètement perdue :
        - revenir au noyau précédent (sans réseau, via le cache de pacman)
        - existence d'un noyau 2.6 LTS
        - pacman -Sc
        - pkgrel

        ça serait tout de même mieux si on pouvait garder simplement les noyaux/modules précédents comme avec debian, et je regrette aussi un peu synaptic, mais j'apprécie d'avoir des paquets très à jour et un desktop plus rapide à démarrer et plus réactif (selon ma perception)

        Envoyé depuis mon Archlinux

        • [^] # Re: Je compatis

          Posté par  . Évalué à 1.

          à ne PAS lire les petites lignes

          Envoyé depuis mon Archlinux

    • [^] # Re: Je compatis

      Posté par  . Évalué à 4.

      Marrant, moi sur ma gentoo j'ai la 2.6.36 depuis plusieurs semaines et je n'ai aucun souci.

      Et vu que le kernel est mis à jour à la main, on garde celui d'avant et on peut toujours rebooter sur celui d'avant sans aucun problème.

      • [^] # Re: Je compatis

        Posté par  . Évalué à 3.

        Ca c’est une fonctionnalité qui mériterait d’être activée par défaut dans Arch, dans d’autres distribution on conserve souvent la possibilité de démarrer sur l’ancien noyau si quelque chose se passe mal. Ici, quelque soit la version du noyau il s’appellera toujours /boot/kernel26.img.

        • [^] # Re: Je compatis

          Posté par  . Évalué à 1.

          Je n'ai pas essayé, mais tu dois pouvoir te faire une copie du « noyau qui fonctionne » et lui rajouter une entrée dans le bootloader.
          Ainsi, tu le gardes en secours quand ton « noyau rolling-release » n'apprécie pas la dernière MaJ.

          Autre solution plus radicale : une slackware ou debian stable en secours (dualboot). Ça te sauve si tu cumules mauvaise mise à jour + boulot urgent au même moment...

          • [^] # Re: Je compatis

            Posté par  (site web personnel) . Évalué à 4.

            ah oui comme avec lilo quand on voulait garder à la fois le noyau 0.9 et le 1.0

          • [^] # Re: Je compatis

            Posté par  . Évalué à 2.

            mauvaise mise à jour + boulot urgent au même moment...
            Il n'y a que moi que ça choque ?

            • [^] # Re: Je compatis

              Posté par  . Évalué à 2.


              Tu ne fais jamais de mise à jour alors que tu dois rendre un rapport le lendemain ?
              Voir simplement lancer une maj entre deux sessions de code intensives.

              • [^] # Re: Je compatis

                Posté par  . Évalué à 3.

                Si c'est X, OOo ou un autre truc vital pour rendre le rapport, ça attend le week-end.

    • [^] # Re: Je compatis

      Posté par  . Évalué à 2.

      > suite à la mise à jour de Xorg, du noyal et du pilote proprio nvidia

      Chez moi aussi c'était galère les mises à jour du noyau et de X, jusqu'à ce que je me décide d'abandonner les drivers proprio.

      • [^] # Re: Je compatis

        Posté par  . Évalué à 2.

        Je voudrai bien m'en débarrasser mais je n'arrive pas à mettre une résolution de 2048x1152 avec les pilotes libres.
        Remarque c'est l'occasion de retenter.

      • [^] # Re: Je compatis

        Posté par  . Évalué à 1.

        Idem, pour moi la mise à jour au 2.6.36-ARCH s'est faite sans un pépin, mais bon, je triche aussi :
        00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
        00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
        0c:00.0 Network controller: Intel Corporation Wireless WiFi Link 5100

        Que du matériel supporté upstream par le constructeur.

        • [^] # Re: Je compatis

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Pareil, matos full Intel et ça marche au poil.
          Et c'est pas faute, depuis 3 ans que je suis sous Arch, de suivre quasi-quotidiennement l'évolution de l'écosystème (passage de ipw à iwl, Xorg modulaire, KMS, xf86-video-intel qui accélère de mieux en mieux, etc).
          Bref, mon système a énormément évolué depuis son passage sous Arch (j'étais sous Slackware avant, imaginez la révolution - c'est KISS pareil, mais bleeding edge !).

          Là, je viens d'installer une Lenny sur un serveur, le noyau est un 2.6.26, c'est pas la même chose ! Mais c'est sur que je ne mettrais pas une Arch sur un serveur de prod...

          Mais bon, c'est vrai qu'il faut un peu se méfier parfois lors des mises à jour, même si les paquets importants restent en testing pendant un moment (s'abonner aux mailing lists pour être au courant de la vie de la distrib est un plus). Une seule fois, une mise à jour du noyau a cassé X, vite réparé.

          Du coup, Ubuntu en rolling release, je me marre. Les mises à jour hebdo de Wayland, ça va être folklo !!!

        • [^] # Re: Je compatis

          Posté par  . Évalué à 2.

          Les derniers kernels avec un / 64 bits + grub1 ça fait pas bon ménage en tout cas.

    • [^] # Re: Je compatis

      Posté par  . Évalué à 2.

      J'ai eu le même soucis avec slackware-current il me semble. Essaie de désactiver le compositing dans xorg pour voir?
      (enfin pas sur parce que j'étais en train de jongler entre nouveau et nvidia à une heure avancée de la nuit et je ne sais plus les détails.)

  • # Ubuntu en rolling release ?

    Posté par  . Évalué à 10.

    En attendant de trouver une solution, je me demande si le choix d’Ubuntu de passer en mode Rolling Release est une bonne idée, je me demande bien comment un utilisateur standard va bien pouvoir s’en sortir sans tripatouiller la configuration en ligne de commandes.
    Non, Ubuntu ne va pas passer en Rolling Release.
    Il n'y a pas encore eu suffisamment de démentis ?
    http://theravingrick.blogspot.com/2010/11/ubuntu-is-not-movi(...) (blog de Rick Spencer, "Engineering Director" d'Ubuntu)

  • # Rolling Release != pointe du progrès

    Posté par  (site web personnel) . Évalué à 3.

    Ce n'est pas parce que l'on désire être en rolling release que l'on doit mettre en péril la stabilité de son parc informatique. La stabilité n'est pas impossible sur ce mode de fonctionnement.

    Par contre il faut accepter de ne pas faire la rolling release sur les toutes dernières versions. Ainsi une rolling release peut être envisagée dans un cadre identique à Debian/testing, en laissant améliorant la stabilité si besoin en prenant toutes les précausions nécéssaires avant leur intégration.

    Ou alors j'espère trop de LMDE.

    Mais je crois savoir que pas mal de monde ici est sur debian testing, voir plus téméraire, le apt-pinning (les logiciels provenant de différents dépôt de debian).

    [troll]PS: en même temps même en version Debian stable, on perd l'assurance de la "stabilité" lorsque l'on installe flash, si mes souvenir sont bon [/troll]

    • [^] # Re: Rolling Release != pointe du progrès

      Posté par  (site web personnel) . Évalué à 2.

      ou alors utiliser un OS avec une base vraiment stable et un ensemble de packages/ports end-user en rolling release ainsi tu as le bonheur complet.

      tu gardes une machine stable et bénéficie rapidement des évolutions. Oui il existe des OS qui fonctionnent comme ça et qui sont libre.

  • # Experimental

    Posté par  . Évalué à 3.

    Aucun système informatique en modification permanente ne pourra satisfaire l'utilisateur non bidouilleur. C'est pourquoi une release majeure tous les 5 ans pourrait suffire, avec des backports des logiciels majeurs (OOo, FF, etc.). Backports signifiant que la version antérieure reste toujours disponible.
    Et aussi backports des pilotes pour tous les nouveaux matériels (gros boulot).

    C'est à peu près ma définition d'un système libre pour tous. On n'en a absolument pas les moyens aujourd'hui, le peu de main d'œuvre libre préférant modfier tout en permanence.

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Experimental

      Posté par  . Évalué à 5.

      En gros il reste quoi de pas mis à jour si on backporte les logiciels majeurs et les pilotes (et donc le noyau et les utilitaires centraux) ?

      Les logiciels mineurs ? Est ce qu'ils seront mineurs pour tout le monde ? Est ce qu'on ne va pas laisser en plan pendant 5 ans des utilisateurs qui auraient eu l'utilité d'une mise à jour ? Et les développeurs ? "Salut ton logiciel est mineur donc tes corrections et tes nouvelles fonctionnalités on s'en cogne, revient dans 5 ans, merci, au revoir."

      Sympa comme système libre.

      • [^] # Re: Experimental

        Posté par  . Évalué à 3.

        J'ai pas dit que c'était le système le plus sympa. Je dis seulement qu'un acheteur lambda de machine tournant sous un système libre ou pas, ne s'attend pas à devoir faire des mises à jour qui cassent des fonctionnalités existantes, avant au moins 5 ans.

        Et oui cet utilisateur va se passer d'une application si elle n'est pas disponible pour son système. Par contre, il sera inquiet si ce système ne propose pas de mises à jour de sécurité.

        C'est le fonctionnement de l'écosystème propriétaire, et que je sache ils ont plus de diffusion que le libre. Une distribution libre qui supprime le choix et assure un support à très long terme me semble avoir ses chances pour ce marché, mais je dois me tromper puisqu'il n'y en a pas...

        Mais je suis bien d'accord que c'est si peu sympa que je n'en veux pas pour moi.

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: Experimental

          Posté par  . Évalué à 2.

          Et oui cet utilisateur va se passer d'une application si elle n'est pas disponible pour son système. Par contre, il sera inquiet si ce système ne propose pas de mises à jour de sécurité.

          Je pense que c'est le contraire, il veut le dernier machin qui va bien et se fout totalement de que son système soit à jour ou non.

          • [^] # Re: Experimental

            Posté par  (site web personnel) . Évalué à 3.

            et moi qui pensait que l'utilisateur ne savait même pas qu'un nouveau machin était dispo (tant que ça marche...), ah il faut une nouvelle version pour de nouvelles fonctionnalités ? il y a de nouvelles fonctionnalités ?

  • # Pas besoin de cable Ethernet !

    Posté par  . Évalué à 7.

    Tu démarre en init 3 (la console).
    Tu te connectes.
    En root tu fait : pacman -U kernel26-2.6.35.x-y.arch.pkg.xz
    Je ne me souviens plus de x et y avant l'upgrade mais l'idée est de prendre le dernier qui fonctionne.
    Tu redémarres. Et tu postes sur arch-general ou sur le forum ou tu rapportes un bug.
    En attendant tu peux mettre kernel26 dans la section IgnorePkg de ton /etc/pacman.conf :
    IgnorePkg=kernel26

    Et hop, ça remarche. Plus qu'à attendre une solution (en contribuant à localiser le problème par exemple).

    • [^] # Re: Pas besoin de cable Ethernet !

      Posté par  . Évalué à 2.

      Merci pour l’info, par contre, lorsqu’on à l’habitude de nettoyer régulièrement le répertoire contenant les paquets téléchargés il est nécessaire d’avoir un accès au réseau pour revenir en arrière. Je suis en train d’étudier plus précisément d’où peut provenir le problème.

      • [^] # Re: Pas besoin de cable Ethernet !

        Posté par  . Évalué à 5.

        sinon sur arch y'a le kernel lts de dispo également :

        > yaourt -Sy kernel26-lts

        ça peut-être utile de l'avoir sous le coude également

      • [^] # Re: Pas besoin de cable Ethernet !

        Posté par  . Évalué à 4.

        Si ce "on" est quelqu'un qui est intelligent et qui a lu la documentation il ne sera pas dans une situation ou le réseau sera obligatoire
        (Non lire la doc ce n'est pas trop demander pour un utilisateur d'Arch, c'est le minimum)

        En effet, "on" utilise pour nettoyer son répertoire de cache la commande pacman -Sc qui permet de conserver les archives de tous les paquets actuellement installés et de virer les autres.

        Cela permet de pouvoir toujours revenir à une configuration stable pour peu que le nettoyage ait été fait dans une situation stable.

      • [^] # Re: Pas besoin de cable Ethernet !

        Posté par  . Évalué à 3.

        Et au pire, il y a downgrade qui permet d'aller prendre dans ARM (Arch Rollback Machine) (https://wiki.archlinux.org/index.php/Downgrading_Packages#AR(...)

        Sinon, un conseil donné dans la doc de Arch Linux concernant l'évolution des paquets, c'est d'introduire une sorte "d'inertie" pour les paquets importants, en gros ne pas mettre à jour tout de suite, attendre un peu (même si ce délai de test devrait être réalisé par l'existence de testing, ca peut pas être parfait).

        Perso, je mets certaines choses dans la directive IgnorePkg de pacman.conf comme kernel26 kernel26-headers, les paquets des drivers catalyst, des paquets de serveurs (icecast, openssh, etc...), etc.

        Une autre idée aussi, c'est d'attendre que le pkgrel (le dernier numéro à la fin du numéro de version après le tiret final) soit plus grand que 1.

  • # BTRFS ...

    Posté par  . Évalué à 6.

    Quoi, tu n'utilises pas btrfs et les snapshots ?

    rolling release + snapshot = bonheur !

    Ca fonctionne pas, tu reviens en arrière,
    tu fais rapport de bug, et tout et tout.

    "J'aime bien jouer avec le feu, mais j'aime pas me bruler !"

    a+

    • [^] # Re: BTRFS ...

      Posté par  . Évalué à 7.

      "J'aime bien jouer avec le feu, mais j'aime pas me bruler !"

      Dit-il du haut de son fs considéré comme pas assez mature pour être utilisé en production.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: BTRFS ...

        Posté par  . Évalué à 5.

        J'aime bien jouer avec le feu, mais j'aime pas me bru

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Maj

    Posté par  (site web personnel) . Évalué à 10.

    Ah ben tiens justement moi aussi je viens de mettre à jo

    • [^] # uscules !

      Posté par  (site web personnel) . Évalué à 1.

      our.


      *tape la poussière sur ses habits*
      Cette porte des étoiles n'est plus ce qu'elle était !

  • # Problème similaire mais différent

    Posté par  . Évalué à 2.

    Plus tôt dans la semaine, j'ai mis à jour mon arch, innocemment, comme d'habitude...
    Puis, au redémarrage de X, ma session ne démarre pas.
    Après inspection de mes logs d'awesome, je constate que celui-ci est linké sur libev.so.3, or ma mise à jour vient de me passer vers libev 4...

    Du coup, retour à la version précédente, et libev a gagné le droit de rejoindre postgresql dans les IGNORE-PKG....
    La mise à jour du noyau, je l'ai faite ce matin et ton journal me décourage de redémarrer.

    Mais je dois aussi ajouter que je ne changerai arch pour rien au monde !

    • [^] # Re: Problème similaire mais différent

      Posté par  . Évalué à 10.

      Mais je dois aussi ajouter que je ne changerai arch pour rien au monde !

      Syndrome de Stockholm.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Problème similaire mais différent

      Posté par  . Évalué à 3.

      Comment as-tu installé awesome? Depuis [archlinuxfr]?

      Si c'est le cas, tu annonce au mainteneur que son paquet doit être reconstruit (3.4.8-1 vers 3.4.8-2) et en attendant qu'il le fasse, tu yaourt -Sb awesome, tu incrémente la variable pkgrel de 1, et tu sors une bière du frigo après ce dur labeur.

      Si tu as installé depuis aur, tu lis les commentaires qui montrent clairement que le mainteneur ne mettra le paquet à jour que lorsque libev4 sortira de community-testing.

      De rien.

      • [^] # Re: Problème similaire mais différent

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        Toutafait.
        C'est la seule fois ou j'ai pesté contre l'approche rolling release, quand j'ai lu sur la mailing list qu'ils allaient arrêter de maintenir Awesome parce que Cairo ne supportait plus officiellement XCB. Mais du coup, j'ai eu le temps de voir venir...

  • # Vous m'avez convaincu

    Posté par  (site web personnel) . Évalué à 10.

    gnumdk et ses déboires avec Redhat qui sont rien que des méchants qui veulent pas le laisser installer pas comme prévu sans qu'il RTFM avant, et les histoires de tu yaourt -Sb awesome, tu incrémente la variable pkgrel de 1 (cf. un commentaire plus haut) m'ont convaincu ; j'abandonne mes Fedora 14 où tout fonctionne hors de la boîte (tout en ayant des versions de paquets bien assez à jour à moins d'être un fétichiste des versions sorties le jour même), pour enfin consacrer mon temps libre à de saines activités comme réparer mon son, mon Xorg, voire encore mieux carrément mon noyau à chaque MàJ.

    • [^] # Re: Vous m'avez convaincu

      Posté par  . Évalué à 2.

      Ce qui fait que j'utilise Arch Linux plutôt qu'une autre, c'est qu'il ont pour principe de garder les paquets les plus "vanilla" possible. Ça me donne l'impression de mieux comprendre ce qu'il se passe (sans doute une psychose du contrôle ou un truc comme ça dirait mon psy, si j'en avait un).

      • [^] # Re: Vous m'avez convaincu

        Posté par  . Évalué à 3.

        Je ne sais pas pour toi, mais pour moi ça ne fait quasiment aucune différence que les sources soient "vanilla" ou pas vu que je ne m'occupe pas trop du code source.

        C'est d'ailleurs un argument qui m'étonne à chaque fois. C'est quoi le problème si les dév d'une distro patchent les paquets?
        Tant qu'ils ne foutent pas le boxon au point où on ne peut plus utiliser certaines fonctionnalités ou que ça plante de partout, je dirais que je ne vois pas la différence.

        • [^] # Re: Vous m'avez convaincu

          Posté par  . Évalué à 1.

          Hum, c'est un argument, dans le sens où ya moins de chances que le problème vienne des patches de la distro, puiqu'il n'y en a… pas. Tu te souviens de l'aléatoire pas si aléatoire que ça sous Debian? C'était pas dû à l'upstream.

        • [^] # Re: Vous m'avez convaincu

          Posté par  . Évalué à 4.

          "Coucou je suis Développeur Debian (Merci de laisser les majuscules, je suis pas n'importe qui vous savez) et je pense que les devs upstream (noté l'absence de majuscules) font n'importe quoi avec leurs logiciels puisqu'ils refusent mes patchs (je suis DD quand même !). Du coup je forke et mon paquet moisit dans un coin parce je n'ai pas le temps de le maintenir convenablement. Mais ce que je maintiens par conter c'est que je sais mieux que l'upstream comment il faut développer leurs logiciels."

          Et je pourrais un peu pareil avec Fedora (et Red-Hat donc), ou Ubuntu (Coucou tu veux voir mon PulseAudio patch à la sauvage ? Hey, regarde mon Wayland aussi !). Sans compter les autre distribution qui vont pécher les patch à droite à gauche. (kikoo-lol-j'ai-téléchargé-les-patchs-fedora-pour-que-GRUB-legacy-supporte-GPT).

          Et puis bon, récupérer des nouvelles fonctionnalité et des corrections de bugs 3 mois après le tag d'une release upstream parce qu'il faut du temps pour porter des patchs in-house, non merci.

          Mais bon, je suis un peu aigri ce matin, j'ai raté mon café.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.