Bug#480818: Don't build depend on libxul-dev
On Mon, Jun 23, 2008 at 11:48 AM, Mike Hommey [EMAIL PROTECTED] wrote: On Mon, Jun 23, 2008 at 10:21:32AM -0700, Shaun Jackman wrote: I just uploaded SWT 3.4~rc3-1 which supports xulrunner 1.9. I usually avoid packaging prereleases unless I have good reason, but this seems like a good reason. Once it makes it through the NEW queue, this bug will be closed. Is it okay with the reverse dependencies ? The only reverse dependency is Azureus, which I maintain, and it'll need a trivial upload, but works fine. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480818: Don't build depend on libxul-dev
On Sat, Jun 21, 2008 at 11:47 PM, Mike Hommey [EMAIL PROTECTED] wrote: On Sat, Jun 21, 2008 at 09:28:17AM -0700, Shaun Jackman wrote: Hi Mike, Thanks for your help so far. I'm starting to get the impression that modifying SWT-GTK to support xulrunner 1.9 is not a trivial amount of work, and that it may be a better plan until upstream supports xulrunner 1.9 explicitly. Since they'll be doing this work anyways, it's a duplication of effort for me to be doing it now, and they'll certainly do a better job of it than I will hacking and slashing code together. How close do you think I am to fixing this? If you'd care look at it yourself, the function that is failing is XPCOM.NS_NewLocalFile in Mozilla.create in Mozilla.java:332. which calls NS_1NewLocalFile in xpcom.cpp:94 which calls NS_NewLocalFile which returns Browser: org.eclipse.swt.SWTError: XPCOM error -1041039359 which corresponds to NS_ERROR_NOT_INITIALIZED. I couldn't immediately see the relation between this function and impl_init from mozilla-embed-single.cpp from epiphany-browser. Could you send your current patch against the last version of swt-gtk in unstable ? Hi Mike, I just uploaded SWT 3.4~rc3-1 which supports xulrunner 1.9. I usually avoid packaging prereleases unless I have good reason, but this seems like a good reason. Once it makes it through the NEW queue, this bug will be closed. Thanks for your help with this bug. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480818: Don't build depend on libxul-dev
On Mon, Jun 23, 2008 at 10:21:32AM -0700, Shaun Jackman wrote: On Sat, Jun 21, 2008 at 11:47 PM, Mike Hommey [EMAIL PROTECTED] wrote: On Sat, Jun 21, 2008 at 09:28:17AM -0700, Shaun Jackman wrote: Hi Mike, Thanks for your help so far. I'm starting to get the impression that modifying SWT-GTK to support xulrunner 1.9 is not a trivial amount of work, and that it may be a better plan until upstream supports xulrunner 1.9 explicitly. Since they'll be doing this work anyways, it's a duplication of effort for me to be doing it now, and they'll certainly do a better job of it than I will hacking and slashing code together. How close do you think I am to fixing this? If you'd care look at it yourself, the function that is failing is XPCOM.NS_NewLocalFile in Mozilla.create in Mozilla.java:332. which calls NS_1NewLocalFile in xpcom.cpp:94 which calls NS_NewLocalFile which returns Browser: org.eclipse.swt.SWTError: XPCOM error -1041039359 which corresponds to NS_ERROR_NOT_INITIALIZED. I couldn't immediately see the relation between this function and impl_init from mozilla-embed-single.cpp from epiphany-browser. Could you send your current patch against the last version of swt-gtk in unstable ? Hi Mike, I just uploaded SWT 3.4~rc3-1 which supports xulrunner 1.9. I usually avoid packaging prereleases unless I have good reason, but this seems like a good reason. Once it makes it through the NEW queue, this bug will be closed. Is it okay with the reverse dependencies ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480818: Don't build depend on libxul-dev
On Sat, Jun 21, 2008 at 09:28:17AM -0700, Shaun Jackman wrote: On Fri, Jun 20, 2008 at 12:03 AM, Mike Hommey [EMAIL PROTECTED] wrote: Hi Mike, If I use pkg-config libxul-embedding, when running Azureus I get the error: Browser: org.eclipse.swt.SWTError: XPCOM error -1041039359 which corresponds to NS_ERROR_NOT_INITIALIZED. With pkg-config libxul it almost works. The embedded browser seems to load because it replaces the Loading... splash screen that Azureus displays, but all I get is a white background. It seems to be almost working though. I don't see any error messages on the console. Where do I go from here? It looks like all you need is to add the xpcom initialization code. The embedding variant needs explicit xpcom loading. You can check how it is done in impl_init() in mozilla-embed-single.cpp in epiphany-browser source, or xulrunner_init() in mozilla.cpp in kazehakase source. You will need to #include gtkmozembed_glue.cpp in the source file doing the initialization. Hi Mike, Thanks for your help so far. I'm starting to get the impression that modifying SWT-GTK to support xulrunner 1.9 is not a trivial amount of work, and that it may be a better plan until upstream supports xulrunner 1.9 explicitly. Since they'll be doing this work anyways, it's a duplication of effort for me to be doing it now, and they'll certainly do a better job of it than I will hacking and slashing code together. How close do you think I am to fixing this? If you'd care look at it yourself, the function that is failing is XPCOM.NS_NewLocalFile in Mozilla.create in Mozilla.java:332. which calls NS_1NewLocalFile in xpcom.cpp:94 which calls NS_NewLocalFile which returns Browser: org.eclipse.swt.SWTError: XPCOM error -1041039359 which corresponds to NS_ERROR_NOT_INITIALIZED. I couldn't immediately see the relation between this function and impl_init from mozilla-embed-single.cpp from epiphany-browser. Could you send your current patch against the last version of swt-gtk in unstable ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480818: Don't build depend on libxul-dev
On Fri, Jun 20, 2008 at 12:03 AM, Mike Hommey [EMAIL PROTECTED] wrote: Hi Mike, If I use pkg-config libxul-embedding, when running Azureus I get the error: Browser: org.eclipse.swt.SWTError: XPCOM error -1041039359 which corresponds to NS_ERROR_NOT_INITIALIZED. With pkg-config libxul it almost works. The embedded browser seems to load because it replaces the Loading... splash screen that Azureus displays, but all I get is a white background. It seems to be almost working though. I don't see any error messages on the console. Where do I go from here? It looks like all you need is to add the xpcom initialization code. The embedding variant needs explicit xpcom loading. You can check how it is done in impl_init() in mozilla-embed-single.cpp in epiphany-browser source, or xulrunner_init() in mozilla.cpp in kazehakase source. You will need to #include gtkmozembed_glue.cpp in the source file doing the initialization. Hi Mike, Thanks for your help so far. I'm starting to get the impression that modifying SWT-GTK to support xulrunner 1.9 is not a trivial amount of work, and that it may be a better plan until upstream supports xulrunner 1.9 explicitly. Since they'll be doing this work anyways, it's a duplication of effort for me to be doing it now, and they'll certainly do a better job of it than I will hacking and slashing code together. How close do you think I am to fixing this? If you'd care look at it yourself, the function that is failing is XPCOM.NS_NewLocalFile in Mozilla.create in Mozilla.java:332. which calls NS_1NewLocalFile in xpcom.cpp:94 which calls NS_NewLocalFile which returns Browser: org.eclipse.swt.SWTError: XPCOM error -1041039359 which corresponds to NS_ERROR_NOT_INITIALIZED. I couldn't immediately see the relation between this function and impl_init from mozilla-embed-single.cpp from epiphany-browser. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480818: Don't build depend on libxul-dev
On Fri, Jun 13, 2008 at 12:35 AM, Mike Hommey [EMAIL PROTECTED] wrote: The first obvious thing would be to ensure you use the proper includes, which means you need, at some point, to use pkgconfig --cflags libxul-embedding. The second thing I would do is ensure it works properly if you build with pkg-config --libs libxul instead of libxul-embedding. When testing this setup, make sure you set the LD_LIBRARY_PATH to /usr/lib/xulrunner-1.9, as it is necessary with what is called the dependent glue (which is what you get with libxul.pc). Once you have things working with this setup, you can switch to libxul-embedding, which requires some additional changes, but we'll see then. Hi Mike, If I use pkg-config libxul-embedding, when running Azureus I get the error: Browser: org.eclipse.swt.SWTError: XPCOM error -1041039359 which corresponds to NS_ERROR_NOT_INITIALIZED. With pkg-config libxul it almost works. The embedded browser seems to load because it replaces the Loading... splash screen that Azureus displays, but all I get is a white background. It seems to be almost working though. I don't see any error messages on the console. Where do I go from here? Thanks, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480818: Don't build depend on libxul-dev
On Thu, Jun 19, 2008 at 11:49:03PM -0700, Shaun Jackman wrote: On Fri, Jun 13, 2008 at 12:35 AM, Mike Hommey [EMAIL PROTECTED] wrote: The first obvious thing would be to ensure you use the proper includes, which means you need, at some point, to use pkgconfig --cflags libxul-embedding. The second thing I would do is ensure it works properly if you build with pkg-config --libs libxul instead of libxul-embedding. When testing this setup, make sure you set the LD_LIBRARY_PATH to /usr/lib/xulrunner-1.9, as it is necessary with what is called the dependent glue (which is what you get with libxul.pc). Once you have things working with this setup, you can switch to libxul-embedding, which requires some additional changes, but we'll see then. Hi Mike, If I use pkg-config libxul-embedding, when running Azureus I get the error: Browser: org.eclipse.swt.SWTError: XPCOM error -1041039359 which corresponds to NS_ERROR_NOT_INITIALIZED. With pkg-config libxul it almost works. The embedded browser seems to load because it replaces the Loading... splash screen that Azureus displays, but all I get is a white background. It seems to be almost working though. I don't see any error messages on the console. Where do I go from here? It looks like all you need is to add the xpcom initialization code. The embedding variant needs explicit xpcom loading. You can check how it is done in impl_init() in mozilla-embed-single.cpp in epiphany-browser source, or xulrunner_init() in mozilla.cpp in kazehakase source. You will need to #include gtkmozembed_glue.cpp in the source file doing the initialization. Cheers, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480818: Don't build depend on libxul-dev
Hi Mike, Switching from using -lxpcomglue in libxul-dev to `pkg-config --libs libxul-embedding` in xulrunner-dev yields the folowing runtime error when running Azureus/Vuze: java: symbol lookup error: /usr/lib/jni/libswt-mozilla-gtk-3346.so: undefined symbol: NS_StringContainerInit2 Any suggestions before the might help speed up my troubleshooting? I'm attempting to run Azureus/Vuze as a test, which uses libswt-mozilla-gtk-3.3-jni, which requires xulrunner. Thanks, Shaun On Mon, May 12, 2008 at 12:07 AM, Mike Hommey [EMAIL PROTECTED] wrote: Package: swt-gtk Severity: wishlist User: [EMAIL PROTECTED] Usertags: xulrunner-transition With the upcoming xulrunner transition, libxul-dev is going to disappear. I already sent instructions on what you should be doing in http://lists.debian.org/debian-release/2008/05/msg9.html This bug report is mostly to help follow the transition going. FYI, I will start NMUing plugins and components next week, and will break the remaining packages by uploading xulrunner 1.9 in unstable on May 25. Though help will be appreciated, I'll also prepare updated packages for these during this week and next. Cheers, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480818: Don't build depend on libxul-dev
On Fri, Jun 13, 2008 at 12:12:27AM -0700, Shaun Jackman [EMAIL PROTECTED] wrote: Hi Mike, Switching from using -lxpcomglue in libxul-dev to `pkg-config --libs libxul-embedding` in xulrunner-dev yields the folowing runtime error when running Azureus/Vuze: java: symbol lookup error: /usr/lib/jni/libswt-mozilla-gtk-3346.so: undefined symbol: NS_StringContainerInit2 Any suggestions before the might help speed up my troubleshooting? The first obvious thing would be to ensure you use the proper includes, which means you need, at some point, to use pkgconfig --cflags libxul-embedding. The second thing I would do is ensure it works properly if you build with pkg-config --libs libxul instead of libxul-embedding. When testing this setup, make sure you set the LD_LIBRARY_PATH to /usr/lib/xulrunner-1.9, as it is necessary with what is called the dependent glue (which is what you get with libxul.pc). Once you have things working with this setup, you can switch to libxul-embedding, which requires some additional changes, but we'll see then. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
