gdk-pixbuf (was Re: gnome 2.8.0 and external dependencies)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yang Guilong wrote: | BTW: Yaakov, I tried to build sylpheed-claws with gdk-pixbuf and | gtk-engines from http://cygwin-ports.sf.net, | everything went fine but the `pixmap' engine | (/usr/lib/gtk/themes/engines/cygpixmap.dll) | couldn't be applied, as it was linked to cyggdk_imlib-1.dll, which I | didn't find. Are you still interested in porting sylpheed-claws? If my gdk-pixbuf port is working, then I'll go ahead and contribute it to the distro. I hope you got my last message about imlib (if not, it's on my project page); that's the only GTK engine that needs it. Is that also a prereq or were you just experimenting? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBdyfzpiWmPGlmQSMRAqCRAKDLNVlEi/ZY+6dezpQ2Bzoo21BWtgCgqnH0 LQvkL1hruvTh/TQD8DtZpXE= =toSe -END PGP SIGNATURE-
Re: gnome 2.8.0 and external dependencies
Hello Charles,
Am Sonntag, 3. Oktober 2004 um 06:49 schriebst du:
Gerrit P. Haase wrote:
Well, you have a struct that is const, so it never changes and new gcc
puts the whole struct into .rdata
static const
struct poptOption cl_libIDL_callback_options[] = {
[snip]
But the important part is that INSIDE the struct, one of the
initialized fields contains the address of a variable. In this case,
although you didn't show it, it's the address of the variable into which
popt is supposed to store the argument for one of the command line
options. E.g. (going from memory)
struct {
option = --bob
short_option = -b
type = POPT_INTEGER
value = my_variable right here
helpstr = blah blah blah
};
So, what's supposed to happen (from popt's perspective) is that the user
types --bob 12 and popt will parse the 12 and store it into my_variable.
However, my_variable is a DATA export from your DLL (it has to be an
export, so that popt can see it).
But the address of DATA exports from DLLs is unknown at link time. The
Windows Runtime Loader has special code (coupled with
declspec(dllexport)/declspec(dllimport)) to fixup this address at
runtime. To avoid declspec hell, on cygwin and mingw, the platform,
compiler and linker cooperate to do something similar, fixing up the
address at runtime to be a function pointer to a trampoline, which
eventually makes it all work.
But it is necessary, in both normal windows and cygwin's
pseudo-runtime-reloc, to UPDATE the address stored in the struct for
my_variable.
But the struct is in .rdata and its contents cannot be changed at runtime.
Better?
Yes, cool. Now I think I can distinguish between 'wrong' and valid
const struct definitions. May I consider using 'const' for structs
which are not really constant (i.e. containig a variable) as harmful?
Gerrit
--
=^..^=
Re: gnome 2.8.0 and external dependencies
Hello Yaakov [snip] Second, remove all symbols with two leading underscores, remove all garbage and newlines and see which symbols are remaining. We should create a handy script to do this. Now, since I found a way around this problem, I think I'll have a version of libbonobo and GConf ready for testing tomorrow. It is difficult. Most of the relevant code in libbonobo is generated by the idl compiler, so this compiler needs to generate valid code. I try to figure out where to change it. Gerrit -- =^..^=
Re: gnome 2.8.0 and external dependencies
Hello Yaakov It is difficult. Most of the relevant code in libbonobo is generated by the idl compiler, so this compiler needs to generate valid code. I try to figure out where to change it. I have changed two things in ORBit: 1. enable build of a running compiler on Cygwin, removed const in one struct in file src/idl-compiler/orbit-idl-main.c. 2. changed the parts code is generated, affected files: include/orbit/orb-core/corba-orb-type.h include/orbit/orb-core/corba-typecode.h src/idl-compiler/orbit-idl-c-headers.c src/idl-compiler/orbit-idl-c-typecode.c src/orb/orb-core/corba-typecode.c With these changes I was able to build executables from the libbonobo package which is running, however, I cannot say if it is also working;) The patch is attached, could you please try and see if it still generates valid code? Gerrit -- =^..^= ORBit2-2.12.0-gerrit.patch Description: Binary data
Re: gnome 2.8.0 and external dependencies
Gerrit P. Haase wrote: Yes, cool. Now I think I can distinguish between 'wrong' and valid const struct definitions. May I consider using 'const' for structs which are not really constant (i.e. containig a variable) as harmful? Yes. But also, structs which contain the (usually constant on all but braindead platforms, like Winblows) ADDRESS of a variable which is imported from a shared lib (DLL), are also not allowed to be const. -- Chuck
Re: gnome 2.8.0 and external dependencies
Charles Wilson wrote: Gerrit P. Haase wrote: Yes, cool. Now I think I can distinguish between 'wrong' and valid const struct definitions. May I consider using 'const' for structs which are not really constant (i.e. containig a variable) as harmful? Yes. But also, structs which contain the (usually constant on all but braindead platforms, like Winblows) ADDRESS of a variable which is imported from a shared lib (DLL), are also not allowed to be const. -- Chuck Windows now has more security features. It's blocking the popup I get from someone one the internet. This morning, I only had two popup, both ActiveX was blocked. I was not using Internet Explorer or Netscape when these popups appeared. Its not Windows thats the problem. Its the hackers who want to get users into Linux or Unix. Linux can act act many things, including an attack base on Windows This system is proteted by Zone Alarm. So hackers, hacking into this system is not wise. I can see you
Re: gnome 2.8.0 and external dependencies
Hello Yaakov,
I cannot run libbonobo executables without getting this stupid access
violation error.
I have all base libraries recompiled, glib2, atk pango are already
uploaded, gtk2-x11 is ready, but I cannot run the executables linked
against these libs. I tried to rebuild IDL ORBit, IDL works,
ORBit fails since I cannot run orbit-idl-2.exe. This means, ORBit
cannot be the culprit since this executable is not linked against
ORBit. Your version is working. Huh. Which gcc version was used to
compile the current releaased ORBit package? I have 3.4.1 here now
and all fails...
Then I'm still far away from really understanding what Charles found
to be the problem with the .rdata sections.
Now, what I found is:
There are exactly three symbols in an .rdata section in the
idl-compiler main object:
_cl_cpp_callback_options
_cl_libIDL_callback_options
_options
The source:
static const
struct poptOption cl_libIDL_callback_options[] = {
[snip]
static const
struct poptOption cl_cpp_callback_options[] = {
[snip]
static const
struct poptOption options[] = {
[snip]
What I did now was to remove the 'const' from these three definitions
and then it works, hurra!
Now I have to dig through at least all objects in packages where I
have failing executables, maybe more.
Take this fix for upcoming ORBit packages and as an example what to do
if there are executables failing.
What I did at first was:
find . -name *.o | xargs nm | grep ' r _' ../.rdata-symbols.list
Second, remove all symbols with two leading underscores, remove all
garbage and newlines and see which symbols are remaining. We should
create a handy script to do this.
Now, since I found a way around this problem, I think I'll have a
version of libbonobo and GConf ready for testing tomorrow.
Gerrit
--
=^..^=
Re: gnome 2.8.0 and external dependencies
Gerrit P. Haase wrote:
Well, you have a struct that is const, so it never changes and new gcc
puts the whole struct into .rdata
static const
struct poptOption cl_libIDL_callback_options[] = {
[snip]
But the important part is that INSIDE the struct, one of the
initialized fields contains the address of a variable. In this case,
although you didn't show it, it's the address of the variable into which
popt is supposed to store the argument for one of the command line
options. E.g. (going from memory)
struct {
option = --bob
short_option = -b
type = POPT_INTEGER
value = my_variable right here
helpstr = blah blah blah
};
So, what's supposed to happen (from popt's perspective) is that the user
types --bob 12 and popt will parse the 12 and store it into my_variable.
However, my_variable is a DATA export from your DLL (it has to be an
export, so that popt can see it).
But the address of DATA exports from DLLs is unknown at link time. The
Windows Runtime Loader has special code (coupled with
declspec(dllexport)/declspec(dllimport)) to fixup this address at
runtime. To avoid declspec hell, on cygwin and mingw, the platform,
compiler and linker cooperate to do something similar, fixing up the
address at runtime to be a function pointer to a trampoline, which
eventually makes it all work.
But it is necessary, in both normal windows and cygwin's
pseudo-runtime-reloc, to UPDATE the address stored in the struct for
my_variable.
But the struct is in .rdata and its contents cannot be changed at runtime.
Better?
--
Chuck
Re: gnome 2.8.0 and external dependencies
Just try the small test program attached below
$ gcc -o localetest localetest.c
$ ./localetest fr_FR
changed to: (null)
current LC_ALl: C
current LC_CTYPE: C
$ gcc -o xlocaletest -DX_LOCALE -I/usr/X11R6/include localetest.c
-L/usr/X11R6/lib -lX11
$ ./xlocaletest fr_FR
changed to: fr_FR
current LC_ALl: fr_FR
current LC_CTYPE: fr_FR
(and IIRC, David Huang sent a message to this list discussing about
this issue last year,
but cgf said there's no one bother to improve the implementation of
the locale support of cygwin1.dl itself)
best regards
Yang Guilong
On Wed, 29 Sep 2004 18:23:54 +0200, Gerrit P. Haase [EMAIL PROTECTED] wrote:
Yang Guilong said the following on 04-09-29 16:16:
And I had just noticed another issue of gtk2: It was linked against
cygwin1.dll's setlocale(), which is taken as problematic.
Why?
When I run gaim-1.0.0 with it, some locale features bahave weird, e.g
the XIM server couldn't be activated.
But when I turn to the gtk2 from cygnome2, everything work fine.
Since gtk2-x11 has something to do with x11, we can turn to XLOCALE.
And that's the way cygnome2 does.
I want to see the reason why it doesn't work with setlocale().
Have you debugged this?
Gerrit
--
=^..^=
- 8 -- localetest.c-
#ifdef X_LOCALE
#include X11/Xlocale.h
#else
#include locale.h
#endif
void check_locale()
{
char *curr;
/* Get the name of the current locale. */
curr=setlocale(LC_ALL, NULL);
printf(current LC_ALl: %s\n, curr);
curr=setlocale(LC_CTYPE, NULL);
printf(current LC_CTYPE: %s\n, curr);
}
int main(int argc, char *argv[])
{
if (argc=1) {
check_locale();
} else {
char *new;
new = setlocale(LC_ALL, argv[1]);
printf(changed to: %s\n, new);
check_locale();
}
return 0;
}
Re: gnome 2.8.0 and external dependencies
On Wed, 29 Sep 2004 03:34:38 +0200, Gerrit P. Haase [EMAIL PROTECTED] wrote: Only libbonobo requires ORBit2; the others could be updated as soon as they're ready. gtk+ is currently 2.4.10, after a number of bugfixes since our 2.4.4. More noticably, atk and pango versions have been bumped, and I know that libgnomeprint-2.8.0 needs pango = 1.5, so updating pango will be helpful. Yes, I will submit them at first. And I had just noticed another issue of gtk2: It was linked against cygwin1.dll's setlocale(), which is taken as problematic. When I run gaim-1.0.0 with it, some locale features bahave weird, e.g the XIM server couldn't be activated. But when I turn to the gtk2 from cygnome2, everything work fine. Since gtk2-x11 has something to do with x11, we can turn to XLOCALE. And that's the way cygnome2 does. BTW: Yaakov, I tried to build sylpheed-claws with gdk-pixbuf and gtk-engines from http://cygwin-ports.sf.net, everything went fine but the `pixmap' engine (/usr/lib/gtk/themes/engines/cygpixmap.dll) couldn't be applied, as it was linked to cyggdk_imlib-1.dll, which I didn't find. best regards Yang Guilong
Re: gnome 2.8.0 and external dependencies
Yang Guilong said the following on 04-09-29 16:16: And I had just noticed another issue of gtk2: It was linked against cygwin1.dll's setlocale(), which is taken as problematic. Why? When I run gaim-1.0.0 with it, some locale features bahave weird, e.g the XIM server couldn't be activated. But when I turn to the gtk2 from cygnome2, everything work fine. Since gtk2-x11 has something to do with x11, we can turn to XLOCALE. And that's the way cygnome2 does. I want to see the reason why it doesn't work with setlocale(). Have you debugged this? Gerrit -- =^..^=
Re: gnome 2.8.0 and external dependencies
Hi Yaakov, I'm pretty sure opencdk is a prereq for gnutls; I'm not sure exactly what gnutls is needed for (gaim? mozilla?), nor libgpg-error or libgcrypt, but they are definitely not necessary for the desktop or core libs. I think they are mentioned there because these packages are all external and not hosted with all the other gnome packages, though they also do explicitly list e.g. libxml2. I think we can skip libfam and mozilla for now;) Do we have a choice? :-) I have tried several times to build mozilla, it shouild work AFAICS, but the build system is a mess, at least I was able to build spidermonkey. Wait for announcements of: libxml2 libxslt gtk-doc glib Are these all up-to-date now? No, I introduced a bug in the glib2 update, I'll upload another update tomorrow. GLib uses dlopen() then. The other three yes, they don't depend on GLib. After I have GLib updated I'll need to recompile atk, pango and gtk+ which were ready but Martin reported the GLib bug so I didn't uploaded them yet. The new updates are based on libtool-1.5.10 now which seems to work fine here. I'm having trouble with ORBit2 suddenly; I've tried both the current version (2.12.0), and then the current port (2.10.3), but neither build now. The first step in building ORBit2 is to build the orbit-idl-2 compiler (dependent on libIDL, which is current), which is then used throughout the rest of the build process to generate C code from IDL files. orbit-idl-2 will compile now, but when it is run I get a *Windows* error message (in a dialog box) saying that the application failed to initialize. (This happened well before my cygheap problem, so I don't think their related.) That is the reason why we must use libtool-1.5.10, there are data symbols in some Glib objects which are tagged with .rdata and when you try to dynamically load them - bang. I got always this crash when GConf loaded gthread.dll. Now I don't find any 'R' tags in /usr/lib, run this: for i in `ls *.dll.a`; do echo $i nm $i | grep ' R '; done in /usr/lib. Obviously, everything worked properly when I first built ORBit2-2.10.3, and that binary package still runs, so it shouldn't be the update to cygwin or glib2, nor autotools because the same ORBit2-2.10.3-1-src package doesn't work now (with the previous autotools), so maybe gcc is the culprit? The current ORBit2-2.10.3-1 was built with gcc-3.3.1-3; could _you_ try building it with gcc-3.3.3-3 and let me know your results? That was mysterious for me too, I compiled GConf the first tiome, it worked, but I didn't included the old locking patches, so it fails to run. Then I fetched Steve's locking patches and after the second build it was broken. I'm not sure if I updated any package between the two builds. What changed is that there are these .rdata tags in symbols. That may well cause such problems. Charles explained exactly why the error happens and that it must be changed in the source, we should look into all the libraries if there are .rdata rtags and then try to patch the sources so that gcc puts these symbols in data sections instead. In the meantime, is ORBit2-2.10.3 sufficient for libbonobo and GConf 2.8? and I'll follow with: intltool libbonobo pango atk gtk+ Only libbonobo requires ORBit2; the others could be updated as soon as they're ready. gtk+ is currently 2.4.10, after a number of bugfixes since our 2.4.4. More noticably, atk and pango versions have been bumped, and I know that libgnomeprint-2.8.0 needs pango = 1.5, so updating pango will be helpful. Yes, I will submit them at first. and then we'll try to get GConf up and running... Unfortunately this is not within my abilities to help fix. Good luck! Now since Charles has found a workaround and we have the new libtool version we can run the apps and debug them. What to do if you even cannot start the application? The only thing I saw was that loading gthread gives my a crash. After all that, I have the following packages ready or almost ready; those with a * need to be updated to Gnome 2.8: [...] I'm not sure how many of the bindings should be in the distro, but I think some of the basics would be nice. Some of the Perl packages are building without modification via cpan shell, so I think these should not be included. After updating that stuff, I'd like to get libgnomeprint, libgnomeprintui, and diacanvas2 next, together with their bindings. But I need to get pango-1.6.0 for that, and more importantly, I need help with my cygheap problem (see the main list from last night). I saw it, I had similar problems once, but I cannot remember the actual solution. Are you sure that there is no other Cygwin DLL in memory? Some commercial applications are installing cygwin1.dll as well! I make a backup in such cases, `format h:` reinstall all the stuff and everytime I'm missing a DLL or a library I pull it out of the backup. What I also did was to buy some more RAM and I added this
Re: gnome 2.8.0 and external dependencies
Gerrit P. Haase wrote: The new updates are based on libtool-1.5.10 now which seems to work fine here. Yay! That is the reason why we must use libtool-1.5.10, there are data symbols in some Glib objects which are tagged with .rdata and when you try to dynamically load them - bang. I got always this crash when GConf loaded gthread.dll. Now I don't find any 'R' tags in /usr/lib, run this: for i in `ls *.dll.a`; do echo $i nm $i | grep ' R '; done in /usr/lib. Well, that's not conclusive. All that means is that so far, one of the following is true: (1) the libs have not been recompiled with a new gcc (= 3.3.3-3) OR (2) the libs do not have any const data items WHICH THEMSELVES CONTAIN pointers to other exported DATA items in their public interface. libtool-1.5.x (x10) had the flaw where it deliberately violated #2. Newer gcc's obligingly put the container item into .rdata -- where the runtime-pseudo-reloc magic couldn't update the *contained* references to the other DATA items. We're actually just sidestepping the issue (Don't do that) by convincing libtool-1.5.10 to declare the container non-const, so it goes into .data where pseudo-reloc can muck with it. That doesn't mean some other package might currently be violating #2. It just means that if so, this mythical other package hasn't yet been recompiled using gcc-3.3.3-3 or newer. Keep your fingers crossed. What changed is that there are these .rdata tags in symbols. That may well cause such problems. Charles explained exactly why the error happens and that it must be changed in the source, we should look into all the libraries if there are .rdata rtags and then try to patch the sources so that gcc puts these symbols in data sections instead. Yep. See above. gmodule-related stuff might be affected by this issue, since glib does its own symbol marshalling and lookup-table definitions. Now since Charles has found a workaround and we have the new libtool version we can run the apps and debug them. What to do if you even cannot start the application? The only thing I saw was that loading gthread gives my a crash. maybe caused by attempts to use thread local storage? I'm not sure how mature the combination of gcc/binutils/cygwin/libtool/tls is. -- Chuck
Re: gnome 2.8.0 and external dependencies
Gerrit P. Haase wrote: I have tried several times to build mozilla, it shouild work AFAICS, but the build system is a mess, at least I was able to build spidermonkey. On X11 I presume? No, I introduced a bug in the glib2 update, I'll upload another update tomorrow. GLib uses dlopen() then. The other three yes, they don't depend on GLib. After I have GLib updated I'll need to recompile atk, pango and gtk+ which were ready but Martin reported the GLib bug so I didn't uploaded them yet. The new updates are based on libtool-1.5.10 now which seems to work fine here. Just to clarify, does this bug affect everything compiled against glib-2.4.6-1, or will everything work as is with the new package? That is the reason why we must use libtool-1.5.10, there are data symbols in some Glib objects which are tagged with .rdata and when you try to dynamically load them - bang. I got always this crash when GConf loaded gthread.dll. Now I don't find any 'R' tags in /usr/lib, run this: for i in `ls *.dll.a`; do echo $i nm $i | grep ' R '; done in /usr/lib. That was mysterious for me too, I compiled GConf the first tiome, it worked, but I didn't included the old locking patches, so it fails to run. Then I fetched Steve's locking patches and after the second build it was broken. I'm not sure if I updated any package between the two builds. What changed is that there are these .rdata tags in symbols. That may well cause such problems. Charles explained exactly why the error happens and that it must be changed in the source, we should look into all the libraries if there are .rdata rtags and then try to patch the sources so that gcc puts these symbols in data sections instead. So for now, it sounds we're waiting for libtool-1.5.10. Later, maybe you could help me so I know what to patch in regards to these .rdata tags. Only libbonobo requires ORBit2; the others could be updated as soon as they're ready. gtk+ is currently 2.4.10, after a number of bugfixes since our 2.4.4. More noticably, atk and pango versions have been bumped, and I know that libgnomeprint-2.8.0 needs pango = 1.5, so updating pango will be helpful. Yes, I will submit them at first. Thanks. Some of the Perl packages are building without modification via cpan shell, so I think these should not be included. I don't know how that's possible (except for the ExtUtils::*); EU::MakeMaker still doesn't like .dll.a, and all the modules are dependent on at least Glib and many of them Gtk2 at link time, and this needs to be specified in cygwin (EU::Depends still doesn't do this). Trust me, I know, I've discussed this before with the gtk2-perl people. Less importantly, to build all the man3 files, a dirty hack is needed for most of the modules. In any case, it should be worth it to include at least Glib and Gtk2. Then there's still PyGTK and the gtkmm bindings. I saw it, I had similar problems once, but I cannot remember the actual solution. Are you sure that there is no other Cygwin DLL in memory? Some commercial applications are installing cygwin1.dll as well! I know about that, and am very careful. I'm sure that wasn't the problem. I make a backup in such cases, `format h:` reinstall all the stuff and everytime I'm missing a DLL or a library I pull it out of the backup. I ended up removing everything but /home and doing a clean reinstall. I think I'm back up and running again. What I also did was to buy some more RAM and I added this to my registry, maybe this helps? REGEDIT4 [HKEY_CURRENT_USER\SOFTWARE\Cygnus Solutions\Cygwin] heap_chunk_in_mb=dword:0400 [HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin] heap_chunk_in_mb=dword:0400 What does this do exactly? Yaakov
Re: gnome 2.8.0 and external dependencies
Gerrit P. Haase wrote: Hello Yaakov, Gnome 2.8.0 is out. So I heard. :-) They list as 'Development Library dependencies': [snip] We are missing some of them: libfam libgpg-error libgcrypt libtasn1 opencdk gnutls libgsf mozilla I think we can skip libfam and mozilla for now;) I really wonder how many of the others are needed up front, or only for one or two applications which come after the desktop is built. The others (besides libgsf) are already available through my server: http://anfaenger.de/cygwin/cygwin-1.5/gnutls/ and also a new version of pth (for libgcrypt) with shared libraries is available: http://anfaenger.de/cygwin/cygwin-1.5/pth/ I have libgsf on my project page. I'll try to update my current range of packages this week and then update and provide the gnutls and others development libraries (using cygwin-1.5.11 with gcc-3.4). Wait for announcements of: libxml2 libxslt gtk-doc glib then you can come with: libIDL ORBit2 libIDL is already up to date (0.8.3-2 = 0.8.4); I'll see what I can do about ORBit2-2.12.0. and I'll follow with: intltool libbonobo pango atk gtk+ Most of these don't have major updates, if I recall, and libbonobo still needs to be added. and then we'll try to get GConf up and running... I think that should be the focus, rather than some of those other prereqs which aren't needed for libgnomeui-2 and the basic desktop. The rest is listed in the new GNOME 2.8 Installation Order list: http://www.gnome.org/start/2.8/notes/rninstallation.html Well, I still have a pending ITP on libglade, and I could build libgnomecanvas and libwnck 2.8 soon I think. What I see to be a real problem is the speed of the ITP process; I have generally seen very little response to my Gnome-related packages, and I've had to ask each time for an exemption due to lack of response. I know these libraries aren't very exciting by themselves, but just the Gnome desktop needs about 30 packages to be operational. With the lag time on these ITPs and upload requests (I don't have upload privileges on cygwin.com), together with the problems with GConf, we missed 2.6 and have to start trying with 2.8. I just hope we get everything up before 2.10 (or whatever they decide to call it). So my question is this: if there's a real commitment to get Gnome into the distro, what can we do to speed this process up? If you visit my project site, you can see how much I have (or had from 2.6) ready. I don't mind doing the work if we can get past this hurdle. Yaakov
Re: gnome 2.8.0 and external dependencies
Hello Yaakov, We are missing some of them: libfam libgpg-error libgcrypt libtasn1 opencdk gnutls libgsf mozilla I think we can skip libfam and mozilla for now;) I really wonder how many of the others are needed up front, or only for one or two applications which come after the desktop is built. I have them ready packaged so there should be no problems. And Volker takes over the GPG parts (gpg-error, gcrypt) and will try to build gnupg on top of them. I have libgsf on my project page. Fine, then I don't care about this one;) Wait for announcements of: libxml2 libxslt gtk-doc glib Oops, I missed to announce gtk-doc, it was already uploaded. then you can come with: libIDL ORBit2 libIDL is already up to date (0.8.3-2 = 0.8.4); I'll see what I can do about ORBit2-2.12.0. Well, I think I can try the GConf build also with the previous versions. What I've seen so far the major change in most of the packages is the version bump;) and I'll follow with: intltool libbonobo pango atk gtk+ Most of these don't have major updates, if I recall, and libbonobo still needs to be added. I have already atk and pango ready for upload, preparing gtk and libbonobo currently. and then we'll try to get GConf up and running... I think that should be the focus, rather than some of those other prereqs which aren't needed for libgnomeui-2 and the basic desktop. Now after Charles found this great fix it should work, at least that I can debug the problems which wasn't possible without downgrading the compiler or some other ugly workarounds. The rest is listed in the new GNOME 2.8 Installation Order list: http://www.gnome.org/start/2.8/notes/rninstallation.html Well, I still have a pending ITP on libglade, and I could build libgnomecanvas and libwnck 2.8 soon I think. What I see to be a real problem is the speed of the ITP process; I have You can upload libglade without waiting for three votes, and I think your packages are always usable, so no review is needed, wasn't that already posted by Corinna too? generally seen very little response to my Gnome-related packages, and I've had to ask each time for an exemption due to lack of response. I know these libraries aren't very exciting by themselves, but just the Gnome desktop needs about 30 packages to be operational. With the lag time on these ITPs and upload requests (I don't have upload privileges on cygwin.com), together with the problems with GConf, we missed 2.6 and have to start trying with 2.8. I just hope we get everything up before 2.10 (or whatever they decide to call it). Alright, I'll upload libglade soon. So my question is this: if there's a real commitment to get Gnome into the distro, what can we do to speed this process up? If you visit my project site, you can see how much I have (or had from 2.6) ready. I don't mind doing the work if we can get past this hurdle. We can upload the most uncritical packages without stepping through all the hurdles. Gerrit -- =^..^=
