lablGtk 2.2.0 is the first release of the new gtk+2 bindings for O'Caml, It includes libgnomecanvas, libgnomepanel, librsvg, libglade and lablgl support. I added two USE flags to reflect the options given by the package (for glade and sgv support). Maybe they should be atvertised somehow, or completely removed in favor of the gnome USE flag. Hope I don't flood you george :)
Created attachment 19684 [details] lablgtk-2.2.0.ebuild The ebuild
Hi Matthieu. Getting through this one. 1. there were multiple whitespace violations - it should be all tab-indented with no trainilg whitespace. repoman recently picked up whitespace checks, but while you cannot use it you can make use of lintool. Just remember that line numbers it reports are 1 off.. 2. RDEPEND=${DEPEND} is not necessary, this one is autosubstituted (a bit confusing which one does and which one doesn't in the beginngng :), I know). On the SLOTting: I see you marked it at 2, which is probably the right thing to do. However it is also necessary to make sure it can coexist with SLOT=1 version. Hm, I got a build failure here. Here is the tail: ocamlc.opt -c -ccopt "-O -DG_DISABLE_CAST_CHECKS -DORBIT2=1 -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtkgl-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2 -I/usr/include/panel-2.0 " ml_panel.c ml_panel.c: In function `ml_panel_applet_factory_main': ml_panel.c:187: error: `GNOME_CLIENT_PARAM_SM_CONNECT' undeclared (first use in this function) ml_panel.c:187: error: (Each undeclared identifier is reported only once ml_panel.c:187: error: for each function it appears in.) make[1]: *** [ml_panel.o] Error 2 make[1]: Leaving directory `/var/tmp/portage/lablgtk-2.2.0/work/lablgtk-2.2.0/src' make: *** [all] Error 2 apparently old version of gnome-panel was to blame, although it is not even listed in dependencies. I added it under gnome? Since there was this problem, I'll attach the modified ebiild for possible more testing, instead of committing it rihgt now. Besides, this will be yet another one which I can help you to commit yourself ;). George
Created attachment 19868 [details] modified lablgtk-2.2.0.ebuild
Hi george! 1. there were multiple whitespace violations - it should be all tab-indented with no trainilg whitespace. repoman recently picked up whitespace checks, but while you cannot use it you can make use of lintool. Just remember that line numbers it reports are 1 off.. So it was a bug :p) I note that it's not documented (e.g: not in http://www.gentoo.org/doc/en/gentoo-howto.xml nor ebuild policy, AFAI researched) 2. RDEPEND=${DEPEND} is not necessary, this one is autosubstituted (a bit confusing which one does and which one doesn't in the beginngng :), I know). As lintool warned me it was a bad thing (and "policy 2.2" didn't help)... As for the SLOT, it should work without problems as lablgtk-2* uses another directory in /usr/lib/ocaml than lablgtk-1*. I have a system where they coexist flawlessly. Sorry about the deps, it seems i missed some and even if i didn't i was not sure which version to ask for, as the README's aren't excessively detailed about gnome dependancies (I think it should compile with gnome-2.2 systems too but I can't test). I attach another modified ebuild with added deps and configure flags.
Created attachment 19872 [details] lablgtk-2.2.0.ebuild 3rd rev Aren't ebuilds text/plain ?
Ok, i'm ready to commit it but i'm concerned there are apps in portage that have dependencies like >=lablgkt-1.2. What am I supposed to do here ? Check every ebuild ? Or maybe they're all dependent on >=lablgtk-1.2.* ?
Hm, I am a bit rusty on the labl* particulars at the moment. Specifically, how compatible 2.x series are with 1.2.x stuff? If 2.2 can be used in place of 1.2, then you can leave >=lablgtk-1.2 (no need for '*' at the end), but if it will cause trouble in the packets that depend on it then it should be changed to =lablgtk-1.2* (no point btw). Correspondingly in the latter case you will need to go through the packages that depend on labltk and change the dependencies (find /usr/portage -iname "*.ebuild"|xargs grep -le labltk will give you the full list). Otherwise, as they have >= anyways in, no need to change anything. George
lablgtk 1 & 2 are not compatible. I only found 2 packages using it, unison and mldonkey. For unison there's no problem, but for the mldonkey ebuilds i'll have to add: DEPEND="gtk? ( >=lablgtk-1.2.4 <lablgtk-2.0 ) to each ebuild. Is it the right way to specify such version numbers ranges ? Say yes and i'll commit fixed mldonkey ebuilds and lablgtk-2.2.0 too.
Well, =lablgtk-1.2* would be the more common way of specifying such dependency (it says pick the latest one of 1.2 series). The one you listed should theoretically work (according to description), but I don't have much experience with this. In any case a brief test of what emerge mldonkey -pe outputs is a usefull thing to do.. George
Problem is, * does not work as expected. In our case, say someone emerge lablgtk-1.2.3, and the tries to emerge mldonkey-2.5.4, which requires lablgtk-1.2* instead of >=lablgtk-1.2.4. emerge -pv mldonkey says it won't get the latest available lablgtk-1.2 version but try to emerge mldonkey with the installed version, and it will fail. I think we spotted a portage bug.
Commited in CVS, now needs testing.
After changing the GTK dependency slightly from: "=x11-libs/gtk+-2.2*" to ">=x11-libs/gtk+-2.2*", it compiled fine against GTK+ 2.3.2 from BMG. I recommend applying this change, because 2.3.2 and 2.2* cannot be installed concurrently AFAIK, and mergeing lablgtk causes GTK+ 2.2* to be installed over 2.3.2.
It seems to be working here. As concerns versions, why don't we do the same thing that was done for gtk+ and gtk+2 (I don't know how they manage the two different major versions, but they are also clearly incompatible).
We do the same thing for lablgtk, that is we use SLOTs.
