Bug#526489: eclipse: should this package be orphaned
On Mon, Jun 15, 2009 at 2:20 PM, Marcus Bettermar...@better.se wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, From: Ana Guerrero a...@debian.org Third and last warning, I will orphan eclipse next saturday (20th June), Perhaps the right thing to do is simply to have eclipse removed from the archive. It is way too outdated to be useful now, and would require *major* work to update. The major work is essentially equivalent to a rewrite (of the packaging). Different jdk, build system, update management, policy, etc etc. Pretty much the only things left will be the boilerplate (debian/copyright files and such). Removing the eclipse 3.2 from the archive would be fine with me, fwiw, especially if it motivates anyone to contribute towards getting 3.5 in. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#526489: eclipse: should this package be orphaned
Removing the eclipse 3.2 from the archive would be fine with me, fwiw, especially if it motivates anyone to contribute towards getting 3.5 in. I think removing directly is not a good idea. It is a widely used application, so I am really hoping somebody gets interested in maintaining it. But if nobody takes over, yes, eventually we should remove it. In the meantime, IMHO it makes sense ask the removal from testing. Eclipse is widely used for sure, it is just the version that is in debian that practically nobody uses these days. Debian users typically just download the upstream binary version instead. Perhaps the eclipse package can be replaced with an installer-type thingie (a-la fwcutter) that just brings in the appropriate dependencies (e.g., openjdk, xulrunner etc) and arranges for the upstream binary to be installed would be the most useful option short term. That is, until upstream gets a sane build system that does not require tons of patches and complexity and us debian people can agree to a policy regarding the packaging of eclipse and collaboration of apt with eclipse's P2. just my 0.02 ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: eclipse version in repository
2009/6/4 Raphaël Vandon vand...@esiee.fr: hello, I saw that the version of eclipse in the repository of debian unstable is the 3.2, while the current version available on the official site is the 3.4. Is there any reason for this ? Actually 3.5 should be out (in eclipse.org) real soon now :-) The reason it is not in debian is that eclipse is notoriously hard to package and the interested parties currently have no free time. You are more than welcome to help though, I 'm happy to provide advice etc. Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: eclipse version in repository
Actually im on the way of repackage it (for my needs) , but im way not a debian developer. This is not a problem, I am not a DD either. We have at least one DD though willing to help with sponsoring etc if the technical problems are solved. What is the policy about eclipse plugins ? should they be in seperate package or in the eclipse Unfortunately there is no official policy for that. It is one of the problems. E.g., a possible issue is Equinox (the eclipse OSGi runtime). It would be best if it were distributed separately (since a few people use it standalone) but this makes maintainance harder. For now a policy that splits eclipse to packages the same way it is done for eclipse 3.2 is probably fine. Important plugins (like cdt/jdt) should be installed in a place like /usr/share/eclipse/dropins, each plugin in its own dir. This avoids interoperability problems with eclipse P2 at least until a better integration between apt/dpkg and P2 is developed. currently im working only on the java part (since that is what i need ) . Well, the core and jdt are by far the hardest, so if you can solve this it will be a big win already. You could look at Fedora's eclipse-build and my eclipse-debian package for some ideas. You could also look at the eclipse-ubuntu project. That one was the most active last time I looked (I think). HTH, Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#432350: eclipse: Starting point
Wouldn't your package from Dec 2008 far better than the current solution. I think so. So, please, upload at least that one to experimental. I 'm sorry but this is just not possible. We cannot pollute debian with crap. My package is (at least was) working and is appropriate for what it was meant to be: a proof of concept and a demonstration of where the problems are. To become uploadable, there are certain things that need to be done to comply with debian policy. As long as those things are not completed, the package would be rejected even if I uploaded it ;) BTW: One thing I don't get is, why that package has that complecity. The only reason in mind is, that it won't work out of box with a free java compiler. If thats the problem, common, move it to non-free. Most users won't care. The ones that care can stick to the two years (!) old version. My package works fine with openjdk so main vs non-free is not a problem. Some of the problems are: 1) Getting eclipse to build from source in a debian setting from the command-line and install it in a way that also allows eclipse's P2 system to work. (A large part of the complexity is devoted to this). 2) Use debian-packaged versions for the jar dependencies that are also eclipse (OSGi) compliant. (My package doesn't solve that). and the various other problems you see in the launchpad bugtracker of the eclipse-debian project. You are welcome to solve these with less complexity. If you manage to do this, the nice folks in the linux-distros project in upstream eclipse.org will more than welcome your contributions :) Cheers, Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#507536: it does not work here either
On Fri, May 1, 2009 at 11:25 AM, Ana Guerrero a...@debian.org wrote: On Fri, May 01, 2009 at 05:32:44AM +0300, Pantelis Koukousoulas wrote: Please try openjdk instead of gcj, gcj has never been really reliable for eclipse afaict. The only reason it was pursued was because it has the right license. Now with openjdk, gcj should probably be deprecated (at least for eclipse). I need to use gcj, if eclipse does not work with it, after the line testing /usr/lib/jvm/java-gcj...found it should stop. Also, make sure you have installed xulrunner-dev or the equivalent. If that doesn't work either, then the problem is that unstable has a too new version of xulrunner for eclipse. If i need to install xulrunner-dev then a depend is missing. Mozilla people tend to change the interfaces at will which tends to break eclipse a lot. The most current breakage (also reported as a Fedora bug) is iirc still being discussed in upstream eclipse's bugzilla. then this depende should be versioned :? Agreed with all the above, but eclipse seems to have no active maintainer right now and the version in debian is trully ancient (the equivalent of kde 2.x). The best solution at this time is probably to remove eclipse altogether from debian until someone with the needed time and dedication can pick it up and bring in the current versions. Until then we 'd just be beating a dead horse, imho. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#507536: it does not work here either
On Thu, Apr 30, 2009 at 10:26 PM, Ana Guerrero a...@debian.org wrote: severity 507536 serious thanks pure unstable/amd64 system here. I just installed eclipse to test something and I got this problem too. When starting eclipse from command line i got: a...@pryan:$ eclipse searching for compatible vm... testing /usr/lib/jvm/java-6-openjdk...not found testing /usr/lib/jvm/java-gcj...found ***Here it stops and i get a popup message: This Eclipse build doesn't have support for the integrated browser. I accept and it continues ... Could not create /usr/local/lib/eclipse/.eclipseextension. Please run as root: touch /usr/local/lib/eclipse/.eclipseextension chmod 2775 /usr/local/lib/eclipse/.eclipseextension chown root:staff /usr/local/lib/eclipse/.eclipseextension /usr/lib/jvm/java-gcj/bin/java: symbol lookup error: /home/ana/.eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.osgi/bundles/46/1/.cp/libswt-mozilla-gtk-3236.so: undefined symbol: _ZN4nsID5ParseEPKc It it the first time I install eclipse (never used it before, really). Please try openjdk instead of gcj, gcj has never been really reliable for eclipse afaict. The only reason it was pursued was because it has the right license. Now with openjdk, gcj should probably be deprecated (at least for eclipse). ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#507536: it does not work here either
Please try openjdk instead of gcj, gcj has never been really reliable for eclipse afaict. The only reason it was pursued was because it has the right license. Now with openjdk, gcj should probably be deprecated (at least for eclipse). Also, make sure you have installed xulrunner-dev or the equivalent. If that doesn't work either, then the problem is that unstable has a too new version of xulrunner for eclipse. Mozilla people tend to change the interfaces at will which tends to break eclipse a lot. The most current breakage (also reported as a Fedora bug) is iirc still being discussed in upstream eclipse's bugzilla. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#432350: New upstream version 3.3.1.1
On Sat, Apr 25, 2009 at 3:36 AM, Christoph Anton Mitterer christoph.anton.mitte...@physik.uni-muenchen.de wrote: ... It's quite embarrassing for Debian to only have such an outdated version of Eclipse (which is nearly identical to not having it at all), or no or only very old versions of the major plugins. Heh, distributions can't feel embarrassment, only people can :P If *you* feel embarrassed, it is pretty easy to relieve yourself from this feeling. Just devote a week (or two) from your life and do what's left to be done :) As long as nobody has the free time / skills / persistence required for a decent package (eclipse is not trivial) there won't be one, it is that simple. If you decide to help and you are not a debian developer, Andreas Tille can do the sponsoring for you and there are a few more resources and help available too. HTH ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#511713: eclipse won't start
On Fri, Feb 6, 2009 at 7:34 PM, Kristóf Kály-Kullai kaku...@gmail.com wrote: A few more information: I have tried to find out exactly which file(s) it needs from xulrunner-dev, and the surprising result is that creating an empty /usr/lib/xulrunner-devel-1.9 folder makes Eclipse starting. I also found in a forum an other workaround, namely it can be started with the command 'java -jar /usr/lib/eclipse/startup.jar'. It looks like the problem is somewhere in /usr/lib/eclipse/eclipse, which is supposed to run startup.jar, plus it also does some other checking and setting up. IIRC, the startup problem is that eclipse wants to show the 'welcome' page in html and wants to use xulrunner for that. This trick (empty dir) probably causes it to not display this page, so it starts correctly. If you want to do something equivalent that does not involve messing with dirs under /usr/lib, you can just put -Dorg.eclipse.swt.browser.XULRunnerPath= in your eclipse.ini after vmargs, or just use that from the command line. You will still have problems though if you want to use the embedded browser for other things like previewing web pages etc. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#511713: eclipse won't start
On Tue, Jan 13, 2009 at 9:46 PM, Aaron Valdes aaronval...@rogers.com wrote: Package: eclipse Version: 3.2.2-6.1 Severity: important When I try to start Eclipse I get this message testing /usr/lib/jvm/java-6-openjdk...found /usr/lib/jvm/java-6-openjdk/bin/java: symbol lookup error: /usr/lib/eclipse/configuration/org.eclipse.osgi/bundles/83/1/.cp/libswt-mozilla-gtk-3236.so: undefined symbol: _ZN4nsID5ParseEPKci I 'm not 100% sure but I think your problem is related to mozilla/libxul. I don't use the 3.2 version of eclipse, but for 3.4 installing libxul-dev had fixed the problem for me. Just some food for thought, Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: [ECLIPSE] Vote for project management solution
On Sat, Dec 20, 2008 at 9:54 PM, Marcus Better mar...@better.se wrote: Hi, Pantelis Koukousoulas wrote: We need a project management system (aka bug tracker) to keep track of the tasks, who is doing what and our progress. Since we're talking about Debian packaging (right?), the Debian BTS should be the obvious choice IMHO. I 'm not so sure about that. The fact is that this eclipse package is not yet even in experimental so it would seem very rude on our part to use the debian BTS for our TODO lists. Similar projects like the experimental kde4-trunk packages also don't use the debian BTS likely for the same reason. Also, please use debian-java for discussions. pkg-java-maintainers is mainly used for BTS mail. I see, unfortunately a few people already have subscribed to this list for coordination but I guess we can try to switch as soon as possible. In any case I just subscribed to debian-java too. Thanks for taking on the huge task of maintaining Eclipse, and best of luck! Thanks, we 'll need it :-) Cheers, Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
[ECLIPSE] First version available :-)
Hello :-) As a christmas present, the first pre-pre-pre-alpha version of an eclipse package is now available :-) Even in this very preliminary stage it should already be better than the other unofficial 3.4.x package in existence. Features: * It should build in * debian sid * ubuntu intrepid + the fakeroot from my PPA (had to track down a FUTEX_WAIT hang, fun :-) * Installing additional plug-ins using P2 should work once you add the ganymede URL manually. The plug-ins will be installed under ~/.eclipse * It should have enough native runtime dependencies so that it actually starts when you install it unlike the blob from eclipse.org :-) (the blob needs you to install manually libxul to get it to work, at least on vanilla ubuntu) * It should work with no obvious bugs, at least I have used it for at least 30 minutes and have not had any problems so far. That is of course, unless I managed to introduce other bugs that testing did not catch :-) * It allows you to work on either dependencies, or packaging extra plug-ins as debian packages or binary subpackages or all of those and have something to test your work with :-) - If things keep working with your changes, most likely your patch will be accepted :-) * I have dropped ALL not-absolutely-essential features in favor of having things work from the POV of the user so it is almost possible to understand how the packaging works :-) (hint: focus on the pretty big/hairy scripts under debian/scripts) * The debian/ folder is available in gitorious (so you don't need to download a 150MB source package just to view the packaging source) git clone git://gitorious.org/eclipse-debian/mainline.git This also means you can use all gitorious cool git features (clone, request merge, etc) * There exists a bug tracker via a Launchpad project in https://bugs.launchpad.net/eclipse-debian with 31 bugs already open (though I think I can now close at least 2 of them :-) Feel free to add more, but check for duplicates first! * GCJ dropped, builds/uses openjdk-6 now which means no bizarre random segfaults all over the place, undoubtedly a good thing :-) * The SWT .so files are built from source. The .so files that come with the source zip are explicitly deleted before the build * Eclipse can now be started with just /usr/bin/eclipse so it is easy to set your desktop shortcuts and such * native libraries that are in .jars (like SWT and a few more) are pre-extracted using the equinox fileinitializer app so you can easily do ldd on them or mount your $HOME with noexec (assuming you don't install more plug-ins like CDT - that need native libraries - via P2) Usage: * debianers: 1) git clone git://gitorious.org/eclipse-debian/mainline.git eclipse-3.4.1 2) cd eclipse-3.4.1 3) debian/rules debian/control (don't be scared by the error message) 4) debian/rules get-orig-source (wait a loong time unless you have super-fast connection) 5) debuild (wait a looong time unless you have your own compile cluster *and* you have it set up so that it parallelizes automatically) 6) Install resulting package with sudo dpkg -i 7) profit: /usr/bin/eclipse goodness :-) * ubunteros * Either go to my PPA page: * https://launchpad.net/~pktoss/+archive/ and copy the binary to your own ppa, or copy *both* the fakeroot and eclipse source packages and let launchpad build them * Or, just enable my ppa in your sources.list: deb http://ppa.launchpad.net/pktoss/ubuntu intrepid main deb-src http://ppa.launchpad.net/pktoss/ubuntu intrepid main and just apt-get install eclipse AND THEN DISABLE THE PPA AGAIN RIGHT AWAY or you *will* break your system with my experimental stuff :-) * Or, install the fakeroot from my ppa and follow the procedure mentioned for debianers You see I 'm all about choice :-) Limitations: (Too many to list here, the below is just a summary, see bugtracker for more details) * I haven't touched any copyright stuff, review is most likely needed. * No binary subpackages. This is for simplicity. A single eclipse-full package installs everything. This means though that we don't play nice (yet) with other packages that need only parts of eclipse. * No symlinked jar dependencies neither at build nor at runtime. Instead we use whatever comes with the source .zip This is against debian policy quite likely. * Installing stuff under
Fwd: Eclipse packaging
I 'm starting to hate gmail ;-) -- Forwarded message -- From: Pantelis Koukousoulas pkt...@gmail.com Date: Sat, Dec 20, 2008 at 8:26 AM Subject: Re: Eclipse packaging To: Ilya consci...@mail.ru On Fri, Dec 19, 2008 at 10:27 PM, Ilya consci...@mail.ru wrote: Hello everybody, I'd also like to help with packaging Eclipse for Debian. Hello llya, You are most welcome :-) Bug 308652 [1] looks reasonably simple for me to work on. At the moment, I have eclipse.menu and eclipse.desktop files as well as several icons, but still have to figure out where to put what. There seems to be no postinst or prerm scripts in the current version (and there are some things to put in them), and I guess build.sh needs to be modified so that icons land in the right place. I'll try to research this on weekend, but if someone has a quick hint I'll appreciate that. [1] https://bugs.launchpad.net/eclipse-debian/+bug/308652 Yes, you will have to add an eclipse-full.postinst and eclipse-full.prerm script with your desktop bits. I think you should put the eclipse-full.menu file straight in debian/ and the rest in debian/extras. You will most likely not have to touch anything in debian/scripts. Testing that it works will be up to you though :-) Btw, it would be wise to look at how this is handled in the current debian package files in svn co svn://svn.debian.org/pkg-java/trunk/eclipse Also, hint: Because the build process takes a lng time it would be wise if you can figure out a way to not have to repeat it every time you change something. So you might have a script for your personal use that does something along the lines of: apt-get remove eclipse-full debian/rules install (or binary) whatever command actually builds a deb cd ..; sudo dpkg -i eclipse-full*.deb; cd - If you figure this out, please post the script on the list for the benefit of others with similar needs :-) Cheers, Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: [ECLIPSE] Do we need an eclipse-specific policy?
On Wed, Dec 17, 2008 at 12:42 PM, Andreas Tille til...@rki.de wrote: On Wed, 17 Dec 2008, Pantelis Koukousoulas wrote: Does that mean we need an eclipse policy following debian tradition? IMHO a clear: YES. Noted, anyone else? Without having had a look at it (because of time constraints): I would try to adopt as much as possible and I would repeat my strong recommendation to join linux-distros-...@eclipse.org for discussing this kind of issues. This discussion will eventually involve linux-distros as well, but debianers will have to voice their opinion too/first :-) Apropos repeating: I will definitely not become a strong member of the pkg-java team but I'm willing to help out with *some* packaging stuff and sponsoring packages. My main concern is to help were some grunt work has to be done because I'm definitely not in the position (spare time wise and knowledge wise) to draw strategic decisions - I just know that cooperation with other projects is cruxial if you know you have sparse manpower. This is cool and it was never my expectation that everyone must have an opinion on everything. My intention with all threads starting with [ECLIPSE] is to state all things that IMHO need discussion *as early as possible*, so that everyone's voice will have a chance to be heard instead of trying to decide the last minute. The deadline for deciding on all these subjects is more like july 2009 when 3.5 comes out so there is no rush. In the meantime we can have a working eclipse package, even if not easily maintainable or debian policy compliant, but still better than previous unofficial attempts :-) So, both for Andreas and the rest of the gang: if you see an [ECLIPSE] mail that you don't have the time to answer to, just ignore it for now, but please *do* try to take it into account if you want to submit a patch to me that deals with these subjects. I don't want to merge patches that touch areas that need discussion, without having this discussion in public first. So, for now, please decide on alioth vs launchpad quickly so that we can start filing bugs and get the grunt work that everyone seems to like started :-) Cheers, Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Fwd: icu4j_3.8.1-1_i386.changes is NEW
-- Forwarded message -- From: Pantelis Koukousoulas pkt...@gmail.com Date: Tue, Dec 16, 2008 at 11:15 AM Subject: Re: icu4j_3.8.1-1_i386.changes is NEW To: Andreas Tille til...@rki.de On Tue, Dec 16, 2008 at 11:10 AM, Andreas Tille til...@rki.de wrote: On Mon, 15 Dec 2008, Rene Engelhard wrote: OOC, why icu4j 3.8.1 and not directly 4.0.0? I was not aware of this new upstream version. I'll try to fix the watch file and upload the new version soon. Well, fedora has 3.8.1 as the dependency for eclipse. Perhaps we would need to check if 4.0.0 is still usable as eclipse 3.4 dependency (due to different major number). Otherwise we might need to patch eclipse or use both. Cheers, Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: Help for eclipse packaging
On Tue, Dec 16, 2008 at 1:31 PM, Broccolalia broccola...@gmail.com wrote: Hi! I've seen you'd like some help for eclipse packaging on launchpad (#123064). I can help you if you want. I'm not an expert in packaging nor in java programming but I've successfully created another package a few months ago and I'm learning java. I have time to work on this (looking for a job...). If you're ok, just tell me what I can do. I'd be glad to help you all! Welcome aboard :) Unfortunately, I 'll be away for the rest of the day today, but let's see how many volunteers we get and If nobody beats me to it, I 'll try to do some task splitting and post a list tomorrow. Cheers, Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
[ECLIPSE] Vote for project management solution
Hello :) We need a project management system (aka bug tracker) to keep track of the tasks, who is doing what and our progress. We seem to have mostly 2 options for that: * An alioth project * A launchpad project I personally like launchpad a bit better due to a friendlier interface and because you can even assign milestones, but I 'm willing to go with whatever the team decides upon. IMHO the most important is to be able to get an account and start working with bugs painlessly and with no questions asked and no paperwork. It seems both the above solutions offer that? What would you prefer / be more comfortable with? Cheers, Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
[ECLIPSE] State of the Art
Hello :) Since we seem to be getting new team members every day (which is already very cool and more than I expected), I thought to post a state of the art to try and get you guys up to speed without you having to do the reverse-engineering that I had to. As you all know it 's been about 2 years (or more?) since eclipse packages have seen any updates that found their way into official debian/ubuntu or that are even reasonably working IMHO. This is what we want to change :) Here 's what we have to work with: First, there is the preliminary debian package work, the packaging files of which (the debian/ folder) can be found in: * svn co svn://svn.debian.org/pkg-java/trunk/eclipse I have not thoroughly studied this work to be honest, mostly because I have looked at the below. Then, there are 2 unofficial ubuntu packages of 3.4.0 (both by Nathan aka Rockwalrus): * The one in https://launchpad.net/~eclipse-team/+archive This seems to be largely based on the above debian work, and for its status I quote rockwalrus himself: I've been working on a package for 3.4 since RC1. I just uploaded a source package to my [[https://launchpad.net/~rock-gimp/+archive ppa]]. It is based off of the never-released packaging for 3.3 in debian's pkg-java svn. There are a few major issues: * Help indexing causes memory corruption, which leads to a crash. This seems to be a gcj-4.2 issue; other jvms don't seem to have this problem. Unfortunately, the source package is set up to build with gcj, so some of the help file packages never get built. Furthermore, if you try to search help files installed using the update manager while running under gcj, eclipse crashes. * The Eclipse source build lost the ability to compile the SWT native libraries sometime between RC1 and the final release. This package uses the .so files that come in the upstream tarball. * There are several jars that were replaced with symlinks to jars in /usr/share/java. Since the 3.4 versions have had osgi properties added to their manifests, this isn't a safe transformation anymore, so those files aren't replaced with symlinks anymore. * P2 doesn't work. If you enable classic update, you can still use it to install new plugins from update sites. Despite all that, I've found it to be reasonably stable and much more useful to me than the 3.2 packages in Hardy. As you probably imagine, all of the above are non-starters :-) * And the one in https://launchpad.net/~rockwalrus/+archive This seems to be a new/fresh effort, with 2 major differences from the above: * Use eclipse's build tools as much as possible (i.e., pdebuild instead of raw Ant) * Use split source packages (i.e., different source packages for eclipse-rcp, eclipse-platform etc) This work is thus split to an eclipse-bootstrap package that contains the core OSGi runtime (equinox) and some Ant machinery and this in turn builds eclipse-rcp, eclipse-platform etc. Unfortunately, this work was never completed and I couldn't get the generated eclipse platform to start successfully (but then maybe I just didn't try hard enough). The above solution seems to be leading to *much* cleaner packaging/building code which is good for obvious reasons, but I 'm scared by the fact that a) This means we pull from CVS, which might get us different code than the one in the source zip b) We seem to need to write various .xml (assemble*.xml etc) files that are included in the source release ourselves (perhaps with every new version?) I have already sent 2 emails with the above questions to Nathan but still no answer (which is OK, since not even a week has passed and he is probably very busy right now). Nevertheless, we have already managed to steal his icu4j package that already has some of the work needed to be useful as an eclipse dependency and we 'll be looking at this approach for a more long-term maintainable solution as well, just probably not now, because right now our goal should be IMHO to get a first working package out fast, sacrificing policy compliance and maintainability if need be :-) --- Which brings us to the good news :-) The good news is that we have a number of factors on our side now that previous teams did not: * There is a free JDK out there now (openjdk) that works fine with eclipse and is free enough for debian main even !!! This means we no longer have to wrestle against GCJ, which is HUGE * Fedora has done most (all) of the work, to get Eclipse 3.4.1 (Ganymede SR1) into Fedora 10. This means we have a clear path to follow for guaranteed success: Copy Fedora where possible :-) Moreover, they have largely documented
[ECLIPSE] Do we need an eclipse-specific policy?
Hello :) Eclipse is its own ecosystem, with all sorts of conventions and peculiarities. In addition, we have several applications each using only particular parts of eclipse e.g., just OSGi/equinox, just RCP, just SWT etc. So, IMHO there is lots of room for incompatibilities and pain, like putting stuff (like .so libraries) in a place where they are hard to find by another package etc. Does that mean we need an eclipse policy following debian tradition? Fedora already has some guidelines that cover * Naming of plugins / applications that just depend on eclipse * Installation locations for core, native libraries, and plugins with and without native code * Other misc stuff You can find those guidelines in http://fedoraproject.org/wiki/Packaging/EclipsePlugins If a debian eclipse policy is needed, what should it contain? Cheers, Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: Bug#432350: ITP: libicu4j-java -- Library for unicode support and internalisation (fwd)
On Mon, Dec 15, 2008 at 4:43 PM, Andreas Tille til...@rki.de wrote: Pantelis, I hope you don't mind if I foreward your PM to the list. Everybody is invited to join this effort. Hopefully it is not me alone who is interested in working on this. No problem at all. I was just pressing the reply button in gmail, thinking the message would go to the list as well, but it seems gmail has a different reply all for that. Since there are many small and more or less independent tasks to be done, the more help we could get the sooner we 'd have eclipse :) So far though you (Andreas) seem to be the only one interested indeed ;-) Cheers, Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: [Eclipse effort] please review icu4j 3.8.1
OK, the package builds find in my pbuilder environment. I do not see any open bugs for libicu4j-java. I would be able to do an upload to Debian mirror on Monday - if nobody insists. Great :) Cheers, Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
[Eclipse effort] please review icu4j 3.8.1
Hi! As part of the effort to get recent eclipse into debian eventually, a seemingly Low Hanging Fruit Job is upgrading icu4j to 3.8.1. There is already a package in https://launchpad.net/~rockwalrus/+archive so it would be nice if a debian developer can review this package and either: * post the problems in this list * fix it and upload it to experimental (?) * fix it and post the updated debian files This way things can still go forward while research is being carried out on how to build/maintain packages for actual eclipse. Thanks, Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: Packaging eclipse 3.4.1 for debian/ubuntu
So my first action now was to subscribe to the list. Done. I also asked to add myself to the alioth project to be able to commit to the development svn. I would advise anybody who really intends to be helpful to follow these two steps. I 'm not a debian developer, would it be possible for me to do this? In any case I think I 'd prefer to keep this unofficial at first and commit to a central repository when we have something reasonably serviceable. For the concrete packaging I would at first suggest to clean up the source packaging. Currently the source tarball contains three zip archives from completely separate upstream projects. IMHO this is no optimal packaging strategy and I would start by packaging icu4j and jsch separately and once this is done create a proper get-upstream-source target for debian/rules to enable newcomers to drop in by providing a defined state of work. Agreed. Btw, It would be nice if interested people drop by #debian-java in OFTC to discuss things in person. Thanks, Pantelis ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
