eclipse packages for !i386 platforms for sarge release
Hallo! A quick look at my 'update-excuses' [1] showed, that eclipse is currently hold back because of several issues: * Some libs, which can't do anything about... * As there are no autobuilder in contrib, I need to provide the platform dependend packages for !i386 platforms. I have no idea, how I should get that happen? Is there anybody, which has the time to build eclipse on PPC or other platforms and can upload the packages? * Another issue is the 'not available' j2sdk1.3/1.4. How is that dealt with? As eclipse will not run without such a thing, I don't know how this can be worked around other than removing all platforms, which have no working JDK [2],[3]: BD/SUN(?): 1.3: powerpc, i386, sparc 1.4: i386, sparc IBM: 1.3: i386, s390(?) 1.4: i386, s390(?) I'm actually not sure, what IBM offers there: They have a JDK for "32-bit xSeries (Intel compatible)", "32-bit iSeries/pSeries", "64-bit iSeries/pSeries", "31-bit zSeries (S/390)" and "64-bit zSeries (S/390)". Maybe someone can enlighten me, what the 'iSeries/pSeries' is and of the last two bits are what debian calls s390... Currently eclipse is shiped mostly as 'Architecture: all', but there are platform dependend modules (JNI -> SWT, other). Also, this libs are not 64bit clean, which is why the libs are already not shiped as 'Arch: any'. What is the recomended way to deal with that problem? Ship as 'Architecture: powerpc i386 s390 sparc' instead of 'Arch: all' and be done with it? Also, will eclipse, with missing dependencies (-> jdks are not packged), move into testing? Theoretically (actually: practically) SWT is runable with kaffe, so swt could be build on other platforms. Eclipse on the other hand will not run on a current kaffe. I'm also very interested in if that's all I can do to get eclipse into the sarge release (other than getting done with the outstanding RC bug...) Jan [1] http://packages.qa.debian.org/e/eclipse.html [2] http://www.blackdown.org/java-linux/java2-status/jdk1.4-status.html [3] https://www6.software.ibm.com/dl/lxdk/lxdk-p signature.asc Description: Digital signature
Re: eclipse packages for !i386 platforms for sarge release
Jan Schulz wrote: Theoretically (actually: practically) SWT is runable with kaffe, so swt could be build on other platforms. Eclipse on the other hand will not run on a current kaffe. However, eclipse will run on gcj: http://sources.redhat.com/eclipse/ http://people.redhat.com/~jhealy/eclipse/ http://mail.gnu.org/archive/html/classpath/2003-08/msg4.html -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: eclipse packages for !i386 platforms for sarge release
On Wed, Oct 29, 2003 at 06:26:48PM +0100, Jan Schulz wrote: > I'm actually not sure, what IBM offers there: They have a JDK for > "32-bit xSeries (Intel compatible)", "32-bit iSeries/pSeries", "64-bit > iSeries/pSeries", "31-bit zSeries (S/390)" and "64-bit zSeries (S/390)". > Maybe someone can enlighten me, what the 'iSeries/pSeries' is and of > the last two bits are what debian calls s390... iSeries are what used to be called AS/400 I think (powerpc and powerpc64). pSeries are what used to be called RS/6000 systems (powerpc and powerpc64). 31-bit zSeries is s390, 64-bit zSeries is s390x. Linux runs on all of these now, I believe. > Currently eclipse is shiped mostly as 'Architecture: all', but there > are platform dependend modules (JNI -> SWT, other). Also, this libs > are not 64bit clean, which is why the libs are already not shiped as > 'Arch: any'. > > What is the recomended way to deal with that problem? Ship as > 'Architecture: powerpc i386 s390 sparc' instead of 'Arch: all' and be > done with it? Also, will eclipse, with missing dependencies (-> jdks > are not packged), move into testing? The JDK dependencies should be ignored for contrib; that's part of its definition (contrib packages can depend on things outside of Debian). Architecture, as I understand it, should be the union of those of the dependencies. So if SWT is only available on 3 architectures, eclipse should use the same Architecture field. You might want to raise the issue on -devel or ask an ftpmaster, though; I'm not entirely clear on the reasons. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: eclipse packages for !i386 platforms for sarge release
On Wednesday 29 October 2003 18:29, Per Bothner wrote: > Jan Schulz wrote: > > Theoretically (actually: practically) SWT is runable with kaffe, so > > swt could be build on other platforms. Eclipse on the other hand will > > not run on a current kaffe. > > However, eclipse will run on gcj: > http://sources.redhat.com/eclipse/ > http://people.redhat.com/~jhealy/eclipse/ > http://mail.gnu.org/archive/html/classpath/2003-08/msg4.html > -- > --Per Bothner > [EMAIL PROTECTED] http://per.bothner.com/ It would certainly be good to have a compiled eclipse in Debian. I suppose we need to find out what patches are needed to gcj/classpath for the current Debian unstable versions to get this to work. There have been a lot of updates to gcj-3.3 and classpath recently, but I have no idea whether we are even near. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: eclipse packages for !i386 platforms for sarge release
Hallo Per, * Per Bothner wrote: >However, eclipse will run on gcj: Yes, I'm aware of that. Unfortunatelly, they use a patched gij/gcj, which is not available in debian yet (AFAIK, they have a branch, which is not completly integrated into HEAD yet. At least that was the message some weeks ago). They also patched eclipse a bit and AFAIK, they haven't made the patches available. Also, I have to either compile it to native, which I probably will not do, at least not without creating a new package for the 'normal' JIT based eclipse. Or I will have to run it woth gij, which is AFAIK interpreter only mode (I've no idea, how it competes with JIT, though). Right now, the gij just crashes after about a minute of >90% CPU... To sum it up: *Right now* I have more hope on kaffe doing the job than gij. Also, the next eclipse version 3.0 (which is next on my TODO) will require 1.4 complient JDKs, and I'm not sure, how far the free JDK are (I guess most can be done with including certain API) in that respect. Jan -- Jan Schulz [EMAIL PROTECTED] "Wer nicht fragt, bleibt dumm." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [ANN] New version of j2se-package (formerly mpkg-j2sdk)
On Mon, 27 Oct 2003, Jan Schulz wrote: > * Hubert Schmid wrote: > >j2se-package creates a (binary) Debian package from an upstream binary > >Java(TM) 2 SDK or RE distribution, in order to easily install the > >non-free Java VMs on Debian machines. > > nitpick: I find the mpkg-* idea better :) What about mpkg-java or > mpkg-j2se? At least it make sit clear that a package is created. I will think about this. But at least, the package and the script should have the same name. > BTW: would you mind to > support the proposed java policy? Some parts were written with > mpkg.java in mind, so it would be great if the proposed things could > happen with it :) You can get the proposed policy from > deb http://www.katzien.de/debian/java ./ I will read the proposed policy this weekend. > If you would tell me which version you will do next, Icould help you > with that. I have a IBM 1.4 JDK here, which I would like to debianize... I will package the blackdown versions next. But I could need some help with the IBM packages, because I don't like to download these files. > It would be nice, if the whole packages could be merged into one source > package. That was a good idea and is already done. regards, Hubert Schmid -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [ANN] New version of j2se-package (formerly mpkg-j2sdk)
On Tue, 28 Oct 2003, Takashi Okamoto wrote: > J2SDK1.3 is used for server purpose by a lot of user. I'll sponsor > your pacakge after supporting Sun's j2sdk1.3. I've just uploaded a new version that supports j2re1.3, j2sdk1.3, j2re1.4 and j2sdk1.4 from Sun. > BTW, kernel-package use 'make-kpkg' command, how about 'make-j2sepkg' or > 'make-jpkg' commands for j2se-package? IMHO 'make-kpkg' isn't a good name, because 'kernel' doesn't occur in it. The package is called 'j2se-package' like 'kernel-package'. The script is also called 'j2se-package', so that users can find it, without executing "dpkg -L", because most people will try the package name as script name. regards, Hubert Schmid -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Undistributable java in main
Hi all! Summary: Usage of GPLed libs to compile GPL-incompatible code makes the result *undistributable*. [0] Affected java packages: Every package that contains GPL-incompatible software which was *compiled* using GPLed libs. Examples: current Ant package apparently(!) has been compiled w/ Kaffe libs which are GPLed. See for ex. unpacked current libant1.5-java: http://www.gadek.homelinux.org/java-illegal/ant/META-INF/MANIFEST.MF More discussion (cleaned up IRC log from #kaffe): http://www.gadek.homelinux.org/java-illegal/gpl-conflicts-log.txt Possible actions (no special order): * Review what java packages (especially the ones that are in "main" and contain GPL incompatible software) have been compiled with * Filling RC bugs for packages that seem to be indistributable * Finding a good way to check/assure what's the license of libs a package has been compiled with * Finding a good way to avoid such problems in the future (ex. by putting some tests into packages' build scripts or by using an improved version of findjava-like tool that understands licenses...) Problems not touched: *execution* of GPL-incompatible code using GPLed libs and/or GPLed JVMs is beyond the scope of this message. Cheers, Grzegorz B. Prokopski [0] AFAIK for the same reason KDE was once removed from Debian completly as linking GPLed code w/ GPL-incompatible license made it not only violate the license but also made the result undistributable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Undistributable java in main
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > Summary: Usage of GPLed libs to compile GPL-incompatible code makes > the result *undistributable*. [0] Does it? AFAIK using gcc (GPL licensed) to compile _any_ software does not make that software GPL. So, why would kaffe be a special case? A pointer to a debian-legal thread is fine :) -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Undistributable java in main
Grzegorz B. Prokopski wrote: Hi all! Hi Grzegorz, Summary: Usage of GPLed libs to compile GPL-incompatible code makes the result *undistributable*. [0] Affected java packages: Every package that contains GPL-incompatible software which was *compiled* using GPLed libs. Examples: current Ant package apparently(!) has been compiled w/ Kaffe libs which are GPLed. See for ex. unpacked current libant1.5-java: http://www.gadek.homelinux.org/java-illegal/ant/META-INF/MANIFEST.MF Well, I'd assume it only means it has been jar-ed with kaffe, but I don't have deeper knowledge of ant's MANIFEST.MF contents. More discussion (cleaned up IRC log from #kaffe): http://www.gadek.homelinux.org/java-illegal/gpl-conflicts-log.txt Since I'm one of the guys (dalibor) discussing this with Grzegorz (gadek) on irc, I guess I should chip in with a comment or two. Since kaffe is a) GPLd and b) somewhat useable, people try to do many things with it. One of them is running programs licensed under a GPL incompatible license. I do it all the time myself, for example. That's all fine and well under the scope of the GPL, as GPL doesn't bother itself with execution, but only poses restrictions on distribution, modification and copying of works. For whatever reason, we get one big 'How does Kaffe's GPL apply to Java programs' IANAL-thread every 3 months. See for example [2] for the last discussion (the time between those discussions decreases as kaffe improves and becomes capable of running more apps). As debian is a distribution, you have to interpret the GPL in one way or the other. (And you usually have debian-legal for that ;)) There are basically two viewpoints on how GPL affects interpreters: A) The FSF[1]: If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses? When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone. However, when the interpreter is extended to provide "bindings" to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a facility; libraries that are accessed in this way are linked dynamically with the Java programs that call them. Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together. A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on. B) me (and I guess a few others who are not lawyers, either): As GPL only really talks about derived works, in order to decide if the GPL applies to a work we must try to see if the new work is derived from a GPLd work, or not. In my opinion a program that's using widely available APIs to accomplish its goals is not bound by the license of the interpreter, as it does not necessarily depend on the GPLd interpreter to run. The GPLd interpreter is not necessary for the creation of a derived work. Many GPL-incompatible java programs run just as fine (and sadly, still quite often somewhat better) on non-free VMs like Sun's VM as on kaffe. The case is even weaker, in my opinion, for the point you're trying to make: for compiling against GPLd widely available runtime APIs (i.e. JRE). AFAIK, the compiled bytecode is equally well (if you're using the JRE APIs) capable of running under a non-GPLd VM, whose runtime classes implement that API. As a small test I wrote a 'Hello' test program and compiled it using jikes against kaffe's rt.jar as the bootclasspath and against JDK 1.4.2's rt.jar. There is *no* difference in the generated bytecode, according to GNU diff. I think that an argument which uses copyright law to allow the same sequence of bits to be licensed under contradictory licenses depending on the components involved (note that I'm not saying contained) in the creation of those bit sequences is contradictory in itself. Beside, you have no means to differentiate between a bit-patter
