{{{ tu parlais d'une variable d'environnement pour rajouter un chemin vers d'autre défaut des clefs gconf? Je n'ai trouvé que GCONF_CONFIG_SOURCE, mais c'est pour le schéma même. car modifier /usr/share/gconf/default.path à chaque fois, ça craint... d'ailleurs, je ne vois pas dans fichier de référence à /usr/share/gconf/[default|mandatory|schemas], c'est builtin dans le démon ? ------------------ [09:40] it's by and large a .desktop file [09:40] pitti: ok, I'm looking at the source package right now. Very similar to what I had in mind [09:40] and a new session script which wraps gnome-session with an env var [09:41] does UNE use gnome-session as well? [09:41] or has its own session program? [09:41] pitti: not sure. At first glance, it should use gnome-session but I need to confirm first (building a VM right now) and make its .desktop files test the session type [09:41] hey vuntz! [09:41] bonjour vuntz, comment vas-tu? [09:41] pitti: ok [09:42] pitti: long hacking night, with some satisfying code in the end [09:42] pitti: what do you mean with "make its .desktop files test the session type" ? [09:43] vuntz: like, don't start a panel or nautilus in a netbook session [09:43] those are started by g-s from gconf keys right now, right? [09:43] ah, it's just a matter of having other desktop files providing Panel and whatever nautilus uses [09:43] and some others are autostart .desktop files [09:44] X-GNOME-Provides=filemanager [09:44] so just drop somewhere a .desktop file with X-GNOME-Provides=filemanager;panel; and voilà! [09:44] (as long as the .desktop file is in a directory with a higher priority than /usr/share/applications) ---- default application: - grepper pour le defaults.list - gio/xdgmime gio/gdesktopappinfo.c: get_all_desktop_entries_for_mime_type (là où il y a l'appel des applications, avec par défault ^ sûrement une modif ici les app utilisent: - g_app_info_get_default_for_uri_scheme - g_app_info_get_default_for_type -> c'est ça ------- [14:10] alors pour -L , c'est pour dire au linker d'aller regarder dans certains paths pour trouver les libs [14:10] c'est l'équivalent de -I, mais au niveau des libs [14:10] tu vois à peu près ? [14:11] euh, mais contrairement au -R, ça ne mets pas dans la lib le path lui-même ? [14:11] voilà [14:11] euh, je vois mal l'utilisation sans que ça fail au runtime alors :/ [14:11] si tu lui file -L/usr/bar/foo -llibbar, il va chercher si il trouve libbar dans /usr/bar/foo, et linker /normalement/ [14:12] ben si [14:12] LD_LIBRARY_PATH :) [14:12] oui, donc tu es obligé de tweeter ton système avant l'utilisation de ta lib [14:12] (ou du bin) [14:12] ouais [14:12] mais c'est ce qui est fait pour ff par exemple [14:12] dac, donc c'est ce que je pensais, je préférais confirmation [14:12] ah ? [14:12] ça permet quand même de garder une certaine flexibilité [14:13] oui, tu encodes pas le path [14:13] yep [14:13] tu peux l'installer dans un /hom/foo/ et l'ajouter au LD_LIBRARY_PATH [14:13] i [14:13] ui* [14:14] dac, il y avait aussi la question de la mixité des .so et -llibname lors du linkage [14:17] ça j'en sais rien [14:17] lintool magic [14:17] libtool [14:18] :) [14:18] donc entre les lignes 1/2/3, tu es aussi un peu flou ? (et l'utilisation du .so ou du .a, la différence ?) [14:19] la ligne 1 n'a rien de fliou, il n'y a rien concernant le link [14:20] entre 2 et 3, la première ligne c'est la commande et la seconde l'output de libtool, donc tu vois que c'est libtool qui fait sa cuisine avec ce qu'on lui file en argument [14:20] oui, il génère un .o sans se préoccuper des libs externes [14:20] et crois-moi tu n'as pas envie de lire ce script [14:20] je te crois sur parole... dès qu'on parle de libtool/autotool, je suis déjà très loin :) [14:20] pour l'utilisation des .so et des .a c'est simple, les .a ce sont les libs statiques [14:20] les .so dynamqiues [14:21] donc lse .a, c'est quand tu veux inclure leur code dans ta lib, c'est ça ? (plus de dép sur le .so installé) [14:21] oui [14:21] et vu que l'option est -llibname, tu indiques comment que tu veux inclure ta lib dans la tienne ? [14:22] inclure la lib dans la tienne* [14:22] t'utilises pas -l [14:22] directement /usr/lib/libfoo.a [14:22] ah, oki [14:22] très clair tout ça :) [14:22] merci beaucoup ! [14:23] ou sinon filer -static à gcc ça doit le faire [14:23] donc ce cas, il les linkeras toutes en statique ? [14:23] mais j'ai toujours eu des embrouilles avec la compile statiques dès que c'est un peu compliqué, donc ... [14:23] «j'en sais rien c'est la merde et toutes façons osef» [14:23] de ton expérience, il y a beaucoup de compile statique ou c'est vraiment plus la règle :) [14:23] ? [14:24] ben non la compile statique c'est le mal absolu [14:24] ça sert juste a rien [14:24] ahah :) [14:24] a part dans l'embarqué [14:24] si tu veux dépendre de la version xxx et pas d'autres [14:24] genre, si upstream fait mal son boulot avec les soname :p [14:24] nan [14:25] plutôt genre ton système a tellement pas d'applications que c'est aussi vite fait d'utiliser un binaire statique [14:25] genre sur des touts petits systèmes ou pratiquement tout est fourni par busybox [14:25] oui, tu as peu d'appli qui auront besoin de la même lib [14:26] dernière chose, ta lib, après être linkée avec /lib/libmalib.so (qui est un lien symbolique vers /lib/libmalib.0.0.0) [14:26] elle utilisera /lib/libmalib.0 au runtime ? [14:27] non [14:27] ça c'est juste dans le cas du rpath [14:28] sinon, à la compile, le linker extrait le SONAME de la librairie sur laquelle tu linke, et colle ça dans le champ DT_NEEDED (me semble) de l'objet que tu créé [14:28] genre libmalib.so.0 [14:28] jusqu'à là, ok... [14:28] après c'est le linker dynamique qui s'amuse à la trouver au runtime [14:28] d'ailleurs tu peux voir ça ave ldd [14:29] genre ldd /usr/lib/libjpeg.so [14:29] à gauche c'est le contenu , à droite la lib vers laquelle c'est résolé [14:29] résolu [14:30] putain je tappe mal aujourd'hui [14:30] je l'ai fait sur irssi et je vois qu'il y parfois des liens vers le .x ou sur le .x.x.x [14:30] pourtant, normalement, les deux sont la même lib, non ? (juste des liens symboliques) [14:30] je peux pas te répondre sans avoir vu ce dont tu parles [14:31] http://pastebin.com/m597cd89f [14:32] je pense avoir compris, là, sur libcrypto.so, il n'y a pas de libcrypto.so.0 par exemple [14:32] ouais mais c'est normal [14:32] le soname de libcrypto c'est libcrypto.so.0.9.8 [14:32] ok, donc aucune garanti de compatibilité d'API entre libcrypto.so.0.9.8 et libcrypto.so.0.9.9 par exemple ? [14:33] voilà [14:33] objdump -p /usr/lib/libcrypto.so | grep SONAME d'ailleurs [14:33] tu verra :) [14:33] oui, je connais pas la commande de tête, mais j'ai déjà expérimé ;) [14:33] vraiment un très très grand merci :) [14:34] tu as enlevé un peu la nébuleuse que j'avais autours de toutes ces problématiques de librairies [14:34] si tu veux vraiment te faire mal au crâne ya le DSO howto, de drepper [14:34] c'est fait pour ça [14:35] * didrocks google [14:35] people.redhat.com/drepper/dsohowto.pdf ---------------- - what is the difference between debug librairies created in dbg-install-% target (and renamed in _d.so) and those created with dh_strip --dbg-package= and residing in usr/lib/debug to reply to the -dbg one, dh_strip moves debug symbols on the side, python-dbg is a different interpreter with different binary and code ----------------- project branches are unchanged (~owner/project/branchname) package branches are ~owner/ubuntu/karmic/package/branchname -------------------------- [13:46] seb128: do you know what's the magic behind gconf in debian? Normally schemas are stored in /etc/gconf and we store it in /usr/share/gconf thanks to dh_gconf as you know. But there is no trace of /usr/... in /etc/gconf/2/path file. Do you know how gconf knows where to look for schemas file? [13:46] (yes, still no-existential question, but I like to understand :D) [13:49] didrocks: the schemas are used at installation time not at runtime [13:50] didrocks: grep schema_location /usr/sbin/gconf-schemas [13:50] didrocks: the path file is a runtime thing, schemas values are writting to var [13:50] seb128: ok, so, only the gconf-schemas call in .postinst is relevant to register schemas. If I change some default values there next, there is no impact at runtime [13:51] seb128: ok, thanks for the info :) [13:51] didrocks: right, schemas are just templates that list keys and values to write [13:51] you need to use gconftool to dump those in the database [13:52] seb128: default values in schemas are then stored in /var/lib/gconf/defaults, right? [13:52] yes [13:52] and I also saw some scripts in /usr/share/gconf/default that overwrite those [13:52] those are stored in /var/lib/gconf/debian.defaults [13:53] which is listed before the defaults directory in the path file you mentioned before [13:53] update-gconf-defaults registers those [13:54] seb128: ok, and files in /usr/share/gconf/default are executed at startup time? Why not just modifying default schemas value at install time? [13:54] didrocks: no, they are debian sort of schemas [13:54] registered using update-gconf-defaults [13:54] because that allows to have a clean order [13:55] - distro default [13:55] - upstream default [13:55] it would also make easy to undo distro changes [13:55] ok, we keep upstream default in schemas and add some kind of "distro default" with the files in /usr/share/gconf/default [13:55] just delete the default and run the registration update ------------------------------------------------------- [21:23] didrocks: hum, we didn't understand each other, I was suggesting splitting by locale as it's done for some other things [21:23] didrocks: so the language-pack can depends on the -locale binary [21:24] seb128: oh. right, we didn't understand each other :) [21:24] seb128: do you have some example to show? [21:25] didrocks: evolution [21:26] didrocks: gimp [21:26] seb128: ok, I will give them a look to see how this is done [21:26] I invalidate the bug, though [21:26] didrocks: it's basically listing a binary-documentation-locale for each locale in the control [21:26] didrocks: and having corresponding .installs [21:27] seb128: are there tools for building that automatically (taken into account the number of locales…) [21:28] didrocks: I don't think so [21:28] didrocks: you can try asking asomething maybe when he's around he did the evolution one [21:29] seb128: I will be interessed when he will be around yes. I'm currently downloading the gimp [21:41] I will let you know but it should be easy [21:42] I grepped through the rdepends of python-gnome2-desktop today [21:42] and there is only gnome-games to fix (and the change is in svn) apparently [21:42] cool! [21:43] so it's just a matter of adding a gnome-python2-gnomeprint binary --------------------- [21:40] I might get libgnomeprint* dropped from the CD too for jaunyt [21:40] great, I will do gnome-games tomorrow [21:40] jaunty [21:40] libgnomeprint is deprecated? [21:40] they are just there because of gnome-python-desktop and gnome-games [21:40] gnome-games is fixed in svn [21:40] and we can split the python binding [21:40] yes for some years by gtkprint in GTK [21:40] ok, if I can give an hand for the split… -------------- [18:54] Xephyr :1 with your normal user [18:54] su testuser [18:54] DISPLAY=:1 dbus-launch gnome-session http://download.gnome.org/sources/pangomm/2.24/pangomm-2.24.0.tar.gz is yours ----------- [22:16] seb128: why this package don't use LP integrated translation? [22:16] didrocks: because translated xml are built during the build and not at runtime [22:17] didrocks: it doesn't fetch the translations at runtime but load localized xml version which are generated during the build [22:19] didrocks: work on updates first, you can keep the "use gettext at runtime" for later, that might be non-trivial ------------ [00:12] didrocks: libraries have a shlibs [00:12] SHVER is an implementation details [00:12] you can also have a .shlibs [00:13] or modify the dh_makeshlibs argument in rules [00:13] the shlibs is the current version of the abi [00:13] ie every time a function is added the shlibs is added [00:13] ok, I write that down somewhere. Each time, there is something to change either, the SHVER, .shlibs, and dh_makeshlibs argument, seing what is presented in the package [00:13] if no function has been added since the first version packaged you might have no shlibs since there is no version restriction [00:14] and some packages use .symbols now which have a better granularity [00:14] in which case you need to update the .symbols and have no shlibs ----------------------- ubuntu-dev-tools: /usr/bin/404main ubuntu-dev-tools: /usr/bin/buildd ubuntu-dev-tools: /usr/bin/check-symbols ubuntu-dev-tools: /usr/bin/dch-repeat ubuntu-dev-tools: /usr/bin/dgetlp ubuntu-dev-tools: /usr/bin/get-branches ubuntu-dev-tools: /usr/bin/get-build-deps ubuntu-dev-tools: /usr/bin/grab-attachments ubuntu-dev-tools: /usr/bin/hugdaylist ubuntu-dev-tools: /usr/bin/massfile ubuntu-dev-tools: /usr/bin/mk-sbuild-lv ubuntu-dev-tools: /usr/bin/pbuilder-dist ubuntu-dev-tools: /usr/bin/pbuilder-dist-simple ubuntu-dev-tools: /usr/bin/pull-debian-debdiff ubuntu-dev-tools: /usr/bin/pull-lp-source ubuntu-dev-tools: /usr/bin/requestsync ubuntu-dev-tools: /usr/bin/reverse-build-depends ubuntu-dev-tools: /usr/bin/submittodebian ubuntu-dev-tools: /usr/bin/suspicious-source ubuntu-dev-tools: /usr/bin/ubuntu-iso ubuntu-dev-tools: /usr/bin/update-maintainer ubuntu-dev-tools: /usr/bin/what-patch }}}