Bug#364368: Build-Dep on mozilla (library), please transition to xulrunner
On 22-Apr-06, at 3:48 PM, Marc 'HE' Brockschmidt wrote: Maybe you've been lucky and upstream already transitioned to use the xulrunner environment. Hi, I work on upstream. We actually build against Mozilla 1.4 since we need to support some old Linux distributions popular in enterprises, but do expect Eclipse to work fine with xulrunner (xulrunner is supposed to be a drop-in replacement for embedding clients). Building against xulrunner should be fine as well, but it's not something we do upstream. Patches appreciated so long as they don't break building against Mozilla 1.4. -Billy ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#352204: eclipse: some times the windows are too small
On 10-Feb-06, at 4:49 AM, Armin Berres wrote: Michael Koch wrote: Please give concret examples, with screenshots if possible. On the fly I found only two windows with this behaviour. If I find more I will make more screenshots. This is a bug in Eclipse (well, I'd also argue in GTK+) that appears with some window managers. It is fixed in version 3.2M4 and newer: https://bugs.eclipse.org/bugs/show_bug.cgi?id=100659 Out of curiosity, what window manager are you using? -Billy ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#351729: noexec home directory policy
It is unclear to me whether a noexec policy on the /home partition is a reasonable thing to do except in very controlled environments. For example, any software downloaded from the net would not run when installed, and plugins for applications such as firefox, or downloaded Eclipse plugins, unless carefully installed globally, would also fail to run. However, see Eclipse bug 90535 for some discussion on solutions for having an install program to globally pre-extract any embedded executables from OSGi bundles. -Billy ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#342341: eclipse: too many unneeded dependencies
On 16-Dec-05, at 3:19 AM, Erwan David wrote: No eclipse (the software) depends on *gtk* libs. Even eclipse.org does not cite gnome as a requirements. *YOU* impose gnome. Erwan, what part about my description of our use of GNOME is confusing? We use GNOME-VFS to implement the Program API. It's used to: - determine what your system web browser is - determine what application should launch if you open the system editor in eclipse - actually run these programs Without GNOME-VFS, the preferences dialog that lists web browsers won't list anything, nor will the listing of external applications for file associations, nor will the open with system editor work, and any applications that depend on the SWT Program API will not work properly. Do you want me to change the Eclipse Platform 3.2 plan on eclipse.org to more clearly state that we depend on gnome-vfs I can do this if it would help! -Billy ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#342341: eclipse: too many unneeded dependencies
Andrew, you don't need to go to such incredible feats of sleuthing. :) I am an SWT developer and I think I already explained quite clearly in this bug report what dependencies are there and what are needed. I have an eclipse.org binary release (3.1.1) unpacked in ~/bin/ eclipse on my sarge install. A quick search shows that this includes private libraries. $ find /home/andrew/bin/eclipse/ |grep '\.so\.\|\.so$' /home/andrew/bin/eclipse/plugins/ org.eclipse.cdt.core.linux.x86_3.0.0/os/linux/x86/libpty.so /home/andrew/bin/eclipse/plugins/ org.eclipse.cdt.core.linux.x86_3.0.0/os/linux/x86/libspawner.so /home/andrew/bin/eclipse/configuration/org.eclipse.osgi/bundles/ 33/1/.cp/libswt-pi-gtk-3139.so /home/andrew/bin/eclipse/configuration/org.eclipse.osgi/bundles/ 33/1/.cp/libswt-gtk-3139.so /home/andrew/bin/eclipse/configuration/org.eclipse.osgi/bundles/ 33/1/.cp/libswt-gnome-gtk-3139.so /home/andrew/bin/eclipse/configuration/org.eclipse.osgi/bundles/ 83/1/.cp/os/linux/x86/libupdate.so /home/andrew/bin/eclipse/configuration/org.eclipse.osgi/bundles/ 10/1/.cp/os/linux/x86/libcore_3_1_0.so /home/andrew/bin/eclipse/libcairo.so.1 (Obviously this is something that the debian eclipse packages don't do). What do you mean by that? All of these libraries, with the exception of libcairo.so.1, are JNI libraries which are part of Eclipse and the C sources are part of the source package, and are definitely installed by the Debian packages. libcairo.so.1 is a precompiled version of cairo as it is not in our supported distributions yet, so clearly this isn't required by the Debian packages yet. A quick ldd shows that the private libraries upstream ships _are_ linked against gnome libs. [...] However it ain't that simple. There has recently been a thread about unused library dependencies [1], [2]. The sarge ldd command does not have the -u option. Therefore I tried ldd -u on ubuntu. ldd -u /home/andrew/bin/eclipse/configuration/org.eclipse.osgi/bundles/ 33/1/.cp/libswt-gnome-gtk-3139.so Unused direct dependencies: /usr/lib/libgnomevfs-2.so.0 /usr/lib/libgnome-2.so.0 /usr/lib/libgnomeui-2.so.0 At this point I'm out of my depth. I don't know how to determine whether (upstreams) libswt-gnome-gtk-3139.so actually _should_ be linked against gnome libs. Since I'm running sarge, it haven't tried ldd on the debian swt libs. I think you're misreading the tools. Here's something clearer to do: $ nm -D libswt-gnome-* | grep gnome_vfs_mime_get_default_application You'll see that it depends on some gnome_vfs symbols. $ nm -D /usr/lib/libgnomevfs-2.so.0 | grep gnome_vfs_mime_get_default_ap You'll see that it's defined here. Now, as explained earlier, this is used by the Eclipse SDK to provide the feature where you go Open With System Editor and the file in Eclipse will open with gedit if that is what is set up in your GNOME preferences. The other feature is that this is also used to determine what your system web browser is, whether it's epiphany or Mozilla or konqueror or whatever. As you mention, other SWT applications may need more of this than the Eclipse SDK. This is true too with the embedded Mozilla. Many teams on the Eclipse project want to hard depend on the embedded browser, and lots of plugins definitely do. However, in the core SDK we've tried to ensure don't completely die if we can't find an embeddable Mozilla/Gecko install. -Billy ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#342341: eclipse: too many unneeded dependencies
On 10-Dec-05, at 8:53 AM, Erwan David wrote: The gnome libraries are needed for SWT, for example org.eclipse.swt.program.Program to get informations about the mine type and icons etc. for a given file. False, eclipse and swt work perfectly without gnome. Hi Erwan, I'm an SWT developer. The Program library is so that in Eclipse, when you right click on a file and go Open With System Editor, it will open the same application that Nautilus would (.txt - gedit, or whatever). As well, .C files will show the right icon the same as nautilus. Of course Eclipse works fine without this capability, but the feature won't work, and other SWT applications may depend on being able to get these icons and runnables (imagine writing a file browser in SWT!). So, at some point the dependency must be stated or moved to be a Recommends:. And the dependency to mozila-broser is needed for the SWT Browser widget. You should be able to use firefox instead, but nevertheless a browser is needed. eclipse works without a browser installed. You put restrictions on its use... Eclipse uses an embedded browser in many places. The Help contents for example is an embedded Mozilla instance. If Mozilla is not found or not available, often there are fallbacks in Eclipse (you'll see some crappy white background with some icons instead of the full Intro), but some other Eclipse plugins _do_ depend on being able to embed mozilla. Consider the Eclipse web development plugins. Even the Javadoc view in Eclipse is an embedded Mozilla browser. Its more a matter of policy : you as maintainer put arbitrary restrictions on the use of the software. I tend to tag the report as WONTFIX, but wait on an opinion from Michael Koch. Do debian policy allow maintainers to include dependencies which are not upstream ? I do not want to use gnome, f I follow you I should stop using debian ? If we (Eclipse) could make these hard dependencies, I think we would. We have a horrible time trying to deal with distributions that don't provide GNOME or Mozilla embedding as part of the standard platform. Please consider how hard it is to ship software under Linux currently where we have to try and ensure we don't _completely_ die when Mozilla/GNOME aren't available. -Billy ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#339435: Wrong freetype?
I don't see how this problem could be specific to Eclipse. Which version of Freetype do you have installed? The FT_GlyphSlot_Embolden is new in a recent version of Freetype and it seems the version of cairo you have installed requires it, but your freetype does not have it. Do other cairo applications on your system work? -Billy ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#336285: Dependency on mozilla-browser
It's not a dependency on the browser, it's a dependency on the Mozilla embedding framework. SWT has an embedded browser widget that requires a gecko runtime engine. -Billy ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
