Journal Xorg dans Sid

Posté par  (site web personnel) .
Étiquettes : aucune
0
18
juil.
2005
Maintenant que Sarge est sorti, ça bouge du coté de de Sid. Xorg vient tout juste d'être intégré, en remplacement de Xfree86.

La licence est plus en accord avec l'esprit debian. Mais au final on gagne un developement plus actif, de meilleurs perfs et les inutiles (donc indispensables) transparence et ombre portées.
Si vous vous embêtez, vous pouvez toujours compter le nombre de fois où le mot.Ubuntu apparait dans le changelog.

http://www.debian-administration.org/articles/185(...)
http://necrotic.deadbeast.net/xsf/XFree86/NEWS.xhtml(...)

  • # dupe

    Posté par  . Évalué à 2.

    j'ai la fleme de chercher, mais y a deja eu un ou 2 journaux sur le sujet...

  • # Commentaire supprimé

    Posté par  . Évalué à -7.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # ABI C++

    Posté par  . Évalué à 2.

    En lisant un peu les annonces relative a l'adoption de Xorg dans SID ici et là, un problême revient souvent : la transition de l'ABI C++.

    Certains mettent en garde et conseillent de ne pas mettre à jour et d'attendre la fin de la transition.

    Souhaitant en savoir un peu plus et n'étant pas expert, j'ai éssayé de comprendre cette histoire d'ABI.

    Après la signification de l'acronyme, ABI voulant dire Application Binary Interface, je pense avoir saisi le principe.

    Certaines librairies utilisées par Xorg étant compilées par une version plus ancienne de GCC (qui casse la compatibilité) celles ci ne peuvent être exploitées correctement par Xorg.

    QQ'un pour confirmer ça ?

    Merci

    • [^] # Re: ABI C++

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

      en fait même les mainteneurs debian de xorg ont pas tout compris
      http://www.livejournal.com/users/gravityboy/16779.html(...)

      • [^] # Re: ABI C++

        Posté par  . Évalué à 1.

        Merci pour le lien. Ils on apparemment compris: ce matin ça fonctionne, X.Org s'installe sans virer libglu et les packages dépendants.

    • [^] # Re: ABI C++

      Posté par  . Évalué à 6.

      C'est l'ABI du C++ qui change. Donc toutes les applications utilisant une bibliothèque C++ doivent être recompilées.

      Le fait est qu'effectivement, cela se passe avec le changement de version de GCC vers la 4.0 (normal aussi, hein, on change pas l'ABI dans une version mineure) et avec le passage de X11 vers Xorg.

      Le passage à Xorg pose aussi quelques problèmes lui-même (sans rapport avec l'ABI), comme p.ex. la modification des dépendances opengl (libglu1 en particulier).

      Donc, en gros, pour bien foutre le bordel en un minimum de temps (vaut mieux tout casser d'un coup, ça sera réparé plus vite), on change : X11 en Xorg, Gcc3 en Gcc4 et l'ABI C++.

      Normalement, debian est faite pour ça : d'autres distributions préfèrent repartir sur une nouvelle version, que l'on ne peut pas mettre à jour depuis les précédentes.
      Faut juste attendre un peu que tout soit recompilé et que les dépendances soient ajustées.

      • [^] # Re: ABI C++

        Posté par  . Évalué à 6.

        en fait, l'ABI change aussi dans gcc-3.4... et pour la libglu, elle est écrite en C++, mais son ABI est en C, donc n'est pas cassée par la transition vers l'ABI de gcc-3.4/4.x.

        En attendant, les devs de Debian réexpliquent les finesses de la transition des ABI pour que le boxon soit réduit à un strict minimum sur lce changement pour Gnome, KDE et autres... ( http://lists.debian.org/debian-devel-announce/2005/07/msg00007.html(...) )

        • [^] # Re: ABI C++

          Posté par  . Évalué à 1.

          Question bête peut-être ?
          Je tourne sous Sid actuellement les "problèmes" que je rencontre actuellement sont sans doute du à ce que vous expliquer. (problème installation application et de dépendence)

          Je me demandais est-ce que ces problèmes peuvent se répercuter sur la debian testing ?

          • [^] # Re: ABI C++

            Posté par  . Évalué à 3.

            Le passage de sid à testing est automatisé de façon à éviter (en principe) les problèmes de dépendances.
            Or, lors des changements d'ABI, les paquets de bibliothèques sont renommés (numérotés), et des Conflicts et Replace sont mis.

            Pour le moment, testing est à l'abri. C'est lors du passage en masse sid->testing de paquets en gros testés que ça risque de casser un peu...

  • # Je m'embete

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

    Si vous vous embêtez, vous pouvez toujours compter le nombre de fois où le mot.Ubuntu apparait dans le changelog.

    $grep Ubuntu Changelog | wc -l
    Et ensuite?
    Pas que je me fasse chier hein, mais...

    • [^] # Re: Je m'embete

      Posté par  . Évalué à 2.

      Mieux:
      $ grep -c Ubuntu Changelog

      En même temps, quand on s'emmerde, c'est peut-être mieux de taper de plus longues lignes de commandes ...

      • [^] # Re: Je m'embete

        Posté par  . Évalué à 3.

        Et le résultat est?
        (j'ai pas de quoi faire la manipe ici :'( )

        • [^] # Re: Je m'embete

          Posté par  . Évalué à 2.

          grep: Changelog: Aucun fichier ou répertoire de ce type

          $ zgrep -ci ubuntu changelog.Debian.gz
          9

  • # licences

    Posté par  . Évalué à 3.

    >La licence est plus en accord avec l'esprit debian

    En même temps, il y a ça
    http://necrotic.deadbeast.net/svn/xorg-x11/trunk/xc/README.crypto(...)

    Ca ne me semble pas libre. Ca veut dire qu'en France, on est limité par les limitations à l'export US.

    Et ça veut aussi dire que si tu est à Cuba et que tu t'es procuré (peut importe comment) tout ça, tu n'as pas le droit de l'utiliser.

    Donc, pas vraiment libre. Cela dit, c'était probablement la même chose avec XF86

  • # XMX ?

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

    Quelqu'un sais si la version debian de xorg est compilée avec le support XMX permettant le multiplexage ?

    http://www.cs.brown.edu/software/xmx/

Suivre le flux des commentaires

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