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] <pitti> it's by and large a .desktop file [09:40] <didrocks> pitti: ok, I'm looking at the source package right now. Very similar to what I had in mind [09:40] <pitti> and a new session script which wraps gnome-session with an env var [09:41] <pitti> does UNE use gnome-session as well? [09:41] <pitti> or has its own session program? [09:41] <didrocks> 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] <didrocks> hey vuntz! [09:41] <pitti> bonjour vuntz, comment vas-tu? [09:41] <didrocks> pitti: ok [09:42] <vuntz> pitti: long hacking night, with some satisfying code in the end [09:42] <vuntz> pitti: what do you mean with "make its .desktop files test the session type" ? [09:43] <pitti> vuntz: like, don't start a panel or nautilus in a netbook session [09:43] <pitti> those are started by g-s from gconf keys right now, right? [09:43] <vuntz> ah, it's just a matter of having other desktop files providing Panel and whatever nautilus uses [09:43] <pitti> and some others are autostart .desktop files [09:44] <vuntz> X-GNOME-Provides=filemanager [09:44] <vuntz> so just drop somewhere a .desktop file with X-GNOME-Provides=filemanager;panel; and voilà! [09:44] <vuntz> (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] <Lutin> alors pour -L , c'est pour dire au linker d'aller regarder dans certains paths pour trouver les libs [14:10] <Lutin> c'est l'équivalent de -I, mais au niveau des libs [14:10] <Lutin> tu vois à peu près ? [14:11] <didrocks> euh, mais contrairement au -R, ça ne mets pas dans la lib le path lui-même ? [14:11] <Lutin> voilà [14:11] <didrocks> euh, je vois mal l'utilisation sans que ça fail au runtime alors :/ [14:11] <Lutin> 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] <Lutin> ben si [14:12] <Lutin> LD_LIBRARY_PATH :) [14:12] <didrocks> oui, donc tu es obligé de tweeter ton système avant l'utilisation de ta lib [14:12] <didrocks> (ou du bin) [14:12] <Lutin> ouais [14:12] <Lutin> mais c'est ce qui est fait pour ff par exemple [14:12] <didrocks> dac, donc c'est ce que je pensais, je préférais confirmation [14:12] <didrocks> ah ? [14:12] <Lutin> ça permet quand même de garder une certaine flexibilité [14:13] <didrocks> oui, tu encodes pas le path [14:13] <Lutin> yep [14:13] <didrocks> tu peux l'installer dans un /hom/foo/ et l'ajouter au LD_LIBRARY_PATH [14:13] <Lutin> i [14:13] <Lutin> ui* [14:14] <didrocks> dac, il y avait aussi la question de la mixité des .so et -llibname lors du linkage [14:17] <Lutin> ça j'en sais rien [14:17] <Lutin> lintool magic [14:17] <Lutin> libtool [14:18] <didrocks> :) [14:18] <didrocks> 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] <Lutin> la ligne 1 n'a rien de fliou, il n'y a rien concernant le link [14:20] <Lutin> 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] <didrocks> oui, il génère un .o sans se préoccuper des libs externes [14:20] <Lutin> et crois-moi tu n'as pas envie de lire ce script [14:20] <didrocks> je te crois sur parole... dès qu'on parle de libtool/autotool, je suis déjà très loin :) [14:20] <Lutin> pour l'utilisation des .so et des .a c'est simple, les .a ce sont les libs statiques [14:20] <Lutin> les .so dynamqiues [14:21] <didrocks> 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] <Lutin> oui [14:21] <didrocks> et vu que l'option est -llibname, tu indiques comment que tu veux inclure ta lib dans la tienne ? [14:22] <didrocks> inclure la lib dans la tienne* [14:22] <Lutin> t'utilises pas -l [14:22] <Lutin> directement /usr/lib/libfoo.a [14:22] <didrocks> ah, oki [14:22] <didrocks> très clair tout ça :) [14:22] <didrocks> merci beaucoup ! [14:23] <Lutin> ou sinon filer -static à gcc ça doit le faire [14:23] <didrocks> donc ce cas, il les linkeras toutes en statique ? [14:23] <Lutin> mais j'ai toujours eu des embrouilles avec la compile statiques dès que c'est un peu compliqué, donc ... [14:23] <Lutin> «j'en sais rien c'est la merde et toutes façons osef» [14:23] <didrocks> de ton expérience, il y a beaucoup de compile statique ou c'est vraiment plus la règle :) [14:23] <didrocks> ? [14:24] <Lutin> ben non la compile statique c'est le mal absolu [14:24] <Lutin> ça sert juste a rien [14:24] <didrocks> ahah :) [14:24] <Lutin> a part dans l'embarqué [14:24] <didrocks> si tu veux dépendre de la version xxx et pas d'autres [14:24] <didrocks> genre, si upstream fait mal son boulot avec les soname :p [14:24] <Lutin> nan [14:25] <Lutin> plutôt genre ton système a tellement pas d'applications que c'est aussi vite fait d'utiliser un binaire statique [14:25] <Lutin> genre sur des touts petits systèmes ou pratiquement tout est fourni par busybox [14:25] <didrocks> oui, tu as peu d'appli qui auront besoin de la même lib [14:26] <didrocks> 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] <didrocks> elle utilisera /lib/libmalib.0 au runtime ? [14:27] <Lutin> non [14:27] <Lutin> ça c'est juste dans le cas du rpath [14:28] <Lutin> 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] <Lutin> genre libmalib.so.0 [14:28] <didrocks> jusqu'à là, ok... [14:28] <Lutin> après c'est le linker dynamique qui s'amuse à la trouver au runtime [14:28] <Lutin> d'ailleurs tu peux voir ça ave ldd [14:29] <Lutin> genre ldd /usr/lib/libjpeg.so [14:29] <Lutin> à gauche c'est le contenu , à droite la lib vers laquelle c'est résolé [14:29] <Lutin> résolu [14:30] <Lutin> putain je tappe mal aujourd'hui [14:30] <didrocks> 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] <didrocks> pourtant, normalement, les deux sont la même lib, non ? (juste des liens symboliques) [14:30] <Lutin> je peux pas te répondre sans avoir vu ce dont tu parles [14:31] <didrocks> http://pastebin.com/m597cd89f [14:32] <didrocks> je pense avoir compris, là, sur libcrypto.so, il n'y a pas de libcrypto.so.0 par exemple [14:32] <Lutin> ouais mais c'est normal [14:32] <Lutin> le soname de libcrypto c'est libcrypto.so.0.9.8 [14:32] <didrocks> ok, donc aucune garanti de compatibilité d'API entre libcrypto.so.0.9.8 et libcrypto.so.0.9.9 par exemple ? [14:33] <Lutin> voilà [14:33] <Lutin> objdump -p /usr/lib/libcrypto.so | grep SONAME d'ailleurs [14:33] <Lutin> tu verra :) [14:33] <didrocks> oui, je connais pas la commande de tête, mais j'ai déjà expérimé ;) [14:33] <didrocks> vraiment un très très grand merci :) [14:34] <didrocks> tu as enlevé un peu la nébuleuse que j'avais autours de toutes ces problématiques de librairies [14:34] <Lutin> si tu veux vraiment te faire mal au crâne ya le DSO howto, de drepper [14:34] <Lutin> c'est fait pour ça [14:35] * didrocks google [14:35] <Lutin> 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] <didrocks> 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] <didrocks> (yes, still no-existential question, but I like to understand :D) [13:49] <seb128> didrocks: the schemas are used at installation time not at runtime [13:50] <seb128> didrocks: grep schema_location /usr/sbin/gconf-schemas [13:50] <seb128> didrocks: the path file is a runtime thing, schemas values are writting to var [13:50] <didrocks> 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] <didrocks> seb128: ok, thanks for the info :) [13:51] <seb128> didrocks: right, schemas are just templates that list keys and values to write [13:51] <seb128> you need to use gconftool to dump those in the database [13:52] <didrocks> seb128: default values in schemas are then stored in /var/lib/gconf/defaults, right? [13:52] <seb128> yes [13:52] <didrocks> and I also saw some scripts in /usr/share/gconf/default that overwrite those [13:52] <seb128> those are stored in /var/lib/gconf/debian.defaults [13:53] <seb128> which is listed before the defaults directory in the path file you mentioned before [13:53] <seb128> update-gconf-defaults registers those [13:54] <didrocks> 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] <seb128> didrocks: no, they are debian sort of schemas [13:54] <seb128> registered using update-gconf-defaults [13:54] <seb128> because that allows to have a clean order [13:55] <seb128> - distro default [13:55] <seb128> - upstream default [13:55] <seb128> it would also make easy to undo distro changes [13:55] <didrocks> ok, we keep upstream default in schemas and add some kind of "distro default" with the files in /usr/share/gconf/default [13:55] <seb128> just delete the default and run the registration update ------------------------------------------------------- [21:23] <seb128> didrocks: hum, we didn't understand each other, I was suggesting splitting by locale as it's done for some other things [21:23] <seb128> didrocks: so the language-pack can depends on the -locale binary [21:24] <didrocks> seb128: oh. right, we didn't understand each other :) [21:24] <didrocks> seb128: do you have some example to show? [21:25] <seb128> didrocks: evolution [21:26] <seb128> didrocks: gimp [21:26] <didrocks> seb128: ok, I will give them a look to see how this is done [21:26] <didrocks> I invalidate the bug, though [21:26] <seb128> didrocks: it's basically listing a binary-documentation-locale for each locale in the control [21:26] <seb128> didrocks: and having corresponding .installs [21:27] <didrocks> seb128: are there tools for building that automatically (taken into account the number of locales…) [21:28] <seb128> didrocks: I don't think so [21:28] <seb128> didrocks: you can try asking asomething maybe when he's around he did the evolution one [21:29] <didrocks> seb128: I will be interessed when he will be around yes. I'm currently downloading the gimp [21:41] <seb128> I will let you know but it should be easy [21:42] <seb128> I grepped through the rdepends of python-gnome2-desktop today [21:42] <seb128> and there is only gnome-games to fix (and the change is in svn) apparently [21:42] <didrocks> cool! [21:43] <seb128> so it's just a matter of adding a gnome-python2-gnomeprint binary --------------------- [21:40] <seb128> I might get libgnomeprint* dropped from the CD too for jaunyt [21:40] <didrocks> great, I will do gnome-games tomorrow [21:40] <seb128> jaunty [21:40] <didrocks> libgnomeprint is deprecated? [21:40] <seb128> they are just there because of gnome-python-desktop and gnome-games [21:40] <seb128> gnome-games is fixed in svn [21:40] <seb128> and we can split the python binding [21:40] <seb128> yes for some years by gtkprint in GTK [21:40] <didrocks> ok, if I can give an hand for the split… -------------- [18:54] <seb128> Xephyr :1 with your normal user [18:54] <seb128> su testuser [18:54] <seb128> DISPLAY=:1 dbus-launch gnome-session http://download.gnome.org/sources/pangomm/2.24/pangomm-2.24.0.tar.gz is yours ----------- [22:16] <didrocks> seb128: why this package don't use LP integrated translation? [22:16] <seb128> didrocks: because translated xml are built during the build and not at runtime [22:17] <seb128> didrocks: it doesn't fetch the translations at runtime but load localized xml version which are generated during the build [22:19] <seb128> didrocks: work on updates first, you can keep the "use gettext at runtime" for later, that might be non-trivial ------------ [00:12] <seb128> didrocks: libraries have a shlibs [00:12] <seb128> SHVER is an implementation details [00:12] <seb128> you can also have a .shlibs [00:13] <seb128> or modify the dh_makeshlibs argument in rules [00:13] <seb128> the shlibs is the current version of the abi [00:13] <seb128> ie every time a function is added the shlibs is added [00:13] <didrocks> 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] <seb128> if no function has been added since the first version packaged you might have no shlibs since there is no version restriction [00:14] <seb128> and some packages use .symbols now which have a better granularity [00:14] <seb128> 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