[Unity] compilation qui pose un problème

[FoolEcho]

Quelques maigres résultats de mes pérégrinations:
- tout ce qui est lié à compiz, pas de problèmes à compiler.
- bamf ne peut se compiler qu'avec la glib2 patchée ! (marche pas avec plus récent comme glib2-git )
- gtk2-appmenu équivaut à un gtk2 patché (j'avais pas compris au début) qui est nécessaire à la compilation de clutk-bzr... mais qui ne compile pas jusqu'au bout (j'ai donc trouvé l'utilité à clutk: permettre la compilation de libunity-misc-git ). Tentative de remplacer par libunity-misc-git, libunity-bzr d'Aur... sans résultat.

En ce qui me concerne, à moins d'un revirement inattendu, je jette l'éponge, désolé. Unity n'est de toutes manières pas KISS avec ses patches dans tous les sens (à moins que glib2 et cie ne finisse par intégrer la pléthore de patch, bien entendu). C'est le développeur objet qui parle aussi: ça me hérisse le poil ce genre de manipulations (parce que j'en ai déjà vu qui retouchaient du code source tiers, libre d'accord, pour coller à leur caprice quand il "suffit" de faire des interfaces... après il faut restester le code tiers, quelle perte de temps... )
Comme je l'ai dit précédemment, mon avis est que ça n'est pas viable pour Arch: si les autres programmes se vautrent à cause d'une bibliothèque qui n'est plus prévue pour eux parce que l'utilisateur remplace la bibliothèque "prévue" par un machin bourré de verrues (pour résumer ici: glib2 et gtk2), c'est bien sûr son droit mais c'est n'importe quoi. Le plus grand risque étant que certains des paquets nécessaires à unity gènent le maintien d'autres paquets en bloquant des versions glib2/gtk2 (l'unité c'est bien, mais certains vont plus ou moins vite...)

Pour info, j'ai trouvé le pourquoi d'un des patchs pour glib2 (qui intervient pour bamfs) https://bugzilla.gnome.org/show_bug.cgi?id=606960
A noter qu'un projet de portage existe sous Arch quand même: Ayatana et qu'un certain nombre de PKGBUILD sont regroupés par là: https://github.com/Dinth/archlinux-ayatana (certains sont obsolètes, et ont fini par se perdre dans qui a besoin de quoi)
Pour voir ce que font les autres aussi... Particulièrement Opensuse que j'ai trouvé intéressant: http://download.opensuse.org/repositori ... .4/x86_64/ (j'ai été tenté de partir de leur rpms... mais bon, c'est pareil, ils sont obligés de patcher à mort et certaines versions sont relativement anciennes: le risque que j'évoquais précédemment).

Mon avis: vous voulez tester unity sous Arch ? Installer Ubuntu en machine virtuelle...

Ce n'est pas pour décourager quiconque veut se lancer là-dedans (la preuve: Yionel a quand même pu avancer sur la compilation de quelques petites choses)... en plus, j'ai peut-être raté des trucs... je suis d'ailleurs prêt à continuer ce sujet si de nouveaux éléments apparaissent.

(sur ce, je rétablis mes bibliothèques glib2 et gtk2... j'ai assez fait mumuse pour l'instant... )

[Yionel]

ok merci alors. Je suis dégoûté. D'un côté ya Arch que j'aime beaucoup mais ya aucun DM ou WM qui me plait (est-ce que je peux mettre gnome normal autre que gnome-shell ?), de l'autre Unity qui me convient mais qui est difficilement portable.

Bon je suis content, j'ai supprimé bamf, remis glib2, viré testing et c'est bon ! j'ai retrouvé ma session gnome-shell. Même si j'aime moins qu'Unity, je préfère à KDE.

[FoolEcho]

On ne peut plus utiliser gnome2, mais tu peux contraindre le mode restreint de gnome3: http://wiki.archlinux.fr/Gnome3#Mode_restreint ... après il y a beaucoup d'autres environnements à découvrir...

[Yionel]

bon niquel, j'ai mis gnome restreint ça me vas

[Yionel]

Bon j'ai montré ton post "Quelques maigres résultats de mes pérégrinations:" à didrock le dev d'Unity.
Il me dit que clutk ainsi que le patch GTK (export des menus) ne sont pas nécessaire du tout.
Il me dit que Gnome patch dans tous les sens pour leur interface en interdisant d'autre.

Le mieux est d'aller sur #ayatana et demander de l'aide la-bas. Cela devrait marcher comme sur des roulettes

Conversation concernant les problème de build :

Code : Tout sélectionner

            +didrocks | Yionel: mais tu devrais pouvoir builder bamf sans ça, c'est juste que la détection est moins précise (elle devient équivalente à
                      | celle de GNOME Shell)
│11:45:40     +Yionel | didrocks: hum apparemment bamf ne se compile qu'avec glib2-ubuntu :'(
│11:45:58     +Yionel | ou alors faut faire un PKGBUILD différent
│11:45:58   +didrocks | Yionel: hum, tu as quoi comme erreur?
│11:46:05     +Yionel | la je ne connais pas assez
│11:47:15     +Yionel | didrocks: je ne me souviens plus :/
│11:47:30   +didrocks | Yionel: en gros, il faudrait que tu enlèves:
│11:47:33   +didrocks | origgiomodulesdir=`pkg-config --variable=giomoduledir gio-2.0`
│11:47:34   +didrocks | # Make giomodulesdir honour 'prefix', so that distcheck works.
│11:47:36   +didrocks | giomodulesdir=`echo "$origgiomodulesdir" | sed 's|/usr|${prefix}|'`
│11:47:38   +didrocks | AC_SUBST(giomodulesdir)
│11:47:46   +didrocks | module/Makefile (un peu plus loin)
│11:47:55   +didrocks | tu lances un autoreconf
│11:47:59   +didrocks | et ça devrait rouler

Je ne suis pas assez expert pour comprendre

[hansi]

Pour ceux qui veulent encore utiliser Gnome 2 il y a un tout nouveau fork apparemment, Mate desktop : http://aur.archlinux.org/packages.php?ID=49902
Bon j'ai pas testé vu qu'il n'y a aucune doc.

[FoolEcho]

Je regarde ça si j'ai 5 minutes.
Pour info, l'erreur de compilation (avec la glib2 d'Arch) tient effectivement à gio:

Code : Tout sélectionner

Making all in module
make[2] : on entre dans le répertoire « /home/ylange/abs/unity/bamf/src/bamf-0.2.90/module »
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..    -I../common -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gio-unix-2.0/    -pthread -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -DG_DISABLE_DEPRECATED  -march=x86-64 -mtune=generic -O2 -pipe -Wno-error=unused-but-set-variable -Wall -Werror -lm -MT libgiobamf_la-gapplaunchhandlerdbus.lo -MD -MP -MF .deps/libgiobamf_la-gapplaunchhandlerdbus.Tpo -c -o libgiobamf_la-gapplaunchhandlerdbus.lo `test -f 'gapplaunchhandlerdbus.c' || echo './'`gapplaunchhandlerdbus.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../common -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gio-unix-2.0/ -pthread -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DG_DISABLE_DEPRECATED -march=x86-64 -mtune=generic -O2 -pipe -Wno-error=unused-but-set-variable -Wall -Werror -lm -MT libgiobamf_la-gapplaunchhandlerdbus.lo -MD -MP -MF .deps/libgiobamf_la-gapplaunchhandlerdbus.Tpo -c gapplaunchhandlerdbus.c  -fPIC -DPIC -o .libs/libgiobamf_la-gapplaunchhandlerdbus.o
gapplaunchhandlerdbus.c:36:40: erreur: unknown type name ‘GDesktopAppInfoLaunchHandlerIface’
gapplaunchhandlerdbus.c: In function ‘g_app_launch_handler_bamf_register_type’:
gapplaunchhandlerdbus.c:46:1: erreur: ‘launch_handler_iface_init’ undeclared (first use in this function)
gapplaunchhandlerdbus.c:46:1: note: each undeclared identifier is reported only once for each function it appears in
gapplaunchhandlerdbus.c:46:1: erreur: ‘G_TYPE_DESKTOP_APP_INFO_LAUNCH_HANDLER’ undeclared (first use in this function)
gapplaunchhandlerdbus.c: Hors de toute fonction :
gapplaunchhandlerdbus.c:99:14: erreur: unknown type name ‘GDesktopAppInfoLaunchHandler’
gapplaunchhandlerdbus.c:148:28: erreur: unknown type name ‘GDesktopAppInfoLaunchHandlerIface’
gapplaunchhandlerdbus.c: In function ‘g_app_launch_handler_bamf_register’:
gapplaunchhandlerdbus.c:157:35: erreur: ‘G_DESKTOP_APP_INFO_LAUNCH_HANDLER_EXTENSION_POINT_NAME’ undeclared (first use in this function)
make[2]: *** [libgiobamf_la-gapplaunchhandlerdbus.lo] Erreur 1
make[2] : on quitte le répertoire « /home/ylange/abs/unity/bamf/src/bamf-0.2.90/module »
make[1]: *** [all-recursive] Erreur 1
make[1] : on quitte le répertoire « /home/ylange/abs/unity/bamf/src/bamf-0.2.90 »
make: *** [all] Erreur 2

EDIT: à tester, bamf compilé avec la glib2 d'Arch (non trafiquée, donc) et donc sans le module gio:
Le PKGBUILD : http://pastebin.archlinux.fr/432871
Le patch utilisé ("disablegio.patch"), à inclure dans le même répertoire que le PKGBUILD, pensez à vérifier la somme de contrôle: http://pastebin.archlinux.fr/432872

"Reste" à voir pour libunity-misc (ou unity-misc)...

[FoolEcho]

Tout se passait bien, j'avais *enfin* tous les pré-requis pour tenter une compilation d'unity... ... qui, bien sûr, a foiré à environ 25% ...

Histoire d'avoir la conscience tranquille, je vérifie notamment les versions des bibliothèques utilisées... Lueur d'espoir, certaines versions ayant changé, je recompile certaines dépendances... et là, paf les versions ne collent plus (dee, de 0.9 à 1.0, etc. ), donc ça plante dès le configure maintenant (vous y avez cru, pas vrai ? ça c'est du contre-pied ).
Bouquet final: unity aussi a changé de version 3.8.16 > 4.0.1 et certaines des autres dépendances ne vont plus du tout, et ce même sur leur versions de développement (bamf... libindicator).

Moralité: ... je savais que je n'aurais pas du faire un mix entre des paquets "stables" et des versions de développement (mais bon, vu que certains paquets d'Aur faisaient l'affaire... )... ... je craque...

Pour faire un petit point niveau dépendances, sans trafiquer les glib2, j'en étais arrivé à un paquet unity qui demandait, directement ou non:
- depuis Aur, inchangé: ccsm-unity-git compizconfig-python-unity-git libcompizconfig-unity-git utouch-geis-bzr dee libindicator-bzr libdbusmenu-bzr (j'suis pas sûr que les builds de ces deux derniers soient bon, en fait... mais de toutes manières la version ne colle plus...)
- nux-bzr (modifié, l'histoire du patch au début de ce sujet)... sauf que la version de développement a changé maintenant 0.9 > 1.0 et demande gtest et gmock pour compiler...
- bamf 0.2.90 (patché, cf. message précédent), ne colle plus avec unity 4
- libunity-misc 4.0.1 (nouveau, pas sur Aur, compilé sans problèmes... mais à l'aide de quelles dépendances ? )
(donc clutk, ido et cie: au tas )

Je vais probablement laisser reposer un peu (je préférerai bosser sur un ensemble cohérent de versions stables, quitte à refaire les builds... plutôt que sur des versions de développement).


EDIT: j'ai juste regardé pour bamf ce midi et la version de développement (0.2.92 -- bamf3 en fait ! ) devrait compiler sans problèmes avec le PKGBUILD suivant (même patch que précédemment): http://pastebin.archlinux.fr/432895

[Yionel]

bon bah ça a avancé c'est cool
J'ai encore pas tout saisi de ce que tu as fait mais ça à l'air pas mal

[FoolEcho]

Pérégrinations du jour, histoire de vous tenir au courant:
- ça ne compile toujours pas... "bien sûr"
- passage aux versions de développement pour tout (bamf-bzr, libunity-misc-bzr, unity-bzr -- cherchez pas sur Aur, tant que l'ensemble ne marche pas, j'vais pas m'amuser à les publier, aucun intérêt... on s'y perd assez comme ça... )

Avec le passage à unity 4.0, ma grosse interrogation tourne autour de "indicator"...
Si je le fais avec libindicator-bzr ( https://launchpad.net/libindicator ), la compilation d'unity plante dès la configuration (normal vu qu'il veut indicator3 ... ): http://pastebin.archlinux.fr/432907
Si je trafique le CMakeLists.txt en remplaçant "indicator3" par "indicator", la compilation se vautre un peu plus loin (mais ça semble lié): http://pastebin.archlinux.fr/432908

Le problème est que je ne trouve pas de libindicator3 (hormis sur Ubuntu, je suppose donc que c'est une version... patchée... je pourrais toujours tenter le coup avec, mais bon...).

[Yionel]

Bah dis donc, tu t'en vois. Moi je suis largué je ne peux pas t'aider