Re: Getting Kaffe into testing, was Re: Accepted kaffe 1:1.1.3-0.2 (powerpc source)
On Tue, Jan 13, 2004 at 06:55:56PM +0100, Stefan Gybas wrote: > Dalibor Topic wrote: > >For other platforms, we essentially need more developers native on those > >platforms to look into the compiler warnings, and fix them (easy step > >one, I guess), and try to fix the crashes (using a prebuilt rt.jar, and > >running the regression test suite, for example). > > Let's assume for a moment that sarge will be released in a couple of > months: Please do assume this. > What about uploading a new Kaffe package with "Architecture: i386 > powerpc"? Architecture: has little effect; you'd also need to get the ftpmasters to remove outdated binaries. If the latter is done then it doesn't matter whether you change Architecture: or not. You'll need to have good justification, though. What do the kaffe developers need to know about the build failures in question? If we knew that, then perhaps a Debian developer with relatively little specific experience of Java could gather the necessary information from a test build. > Objections? You may well find that not as many packages move to testing as you might hope, because they are built for architectures for which kaffe is not under your proposal. > Better suggestions? Fix the build problems. :) Hey, it built on those architectures in the past, didn't it? -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Report from the Debian Java developers meeting at FOSDEM
On Wed, Mar 03, 2004 at 09:49:44PM +0100, Dalibor Topic wrote: > Stefan Gybas wrote: > >Main discussions with Java developers > > > >Besides the issue of better collaboration we also had a lot of technical > >discussions: > > > >- The proposed new Debian Java Policy by Jan Schulz > > That's got time till the next debian release is out, I guess. Not an awful lot of it (assuming the 15th March date for the base freeze holds or doesn't slip too far). -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#90243: ITP: jdk1.3 -- Java Development Kit
Maurizio Boriani <[EMAIL PROTECTED]> wrote: >On Mon, Mar 19, 2001 at 10:09:31AM +0000, Colin Watson wrote: >> Maurizio Boriani <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: >> >Package: wnpp >> >Severity: wishlist >> >URL: ftp://ftp.progsoc.uts.edu.au/pub/Linux/java/JDK-1.3.0/ >> > >> >This is Sun Java Development kit from blackdown. Sun permit this version >> >redistribution unlike sun download ftp server. >> >> Um, in http://lists.debian.org/debian-java-0103/msg00091.html Stephen >> Zander (jdk1.1 maintainer) said he was going to package this now that >> the legalities have been sorted out ... have I missed something? > >This legalities was denied for any other to redistribuite jdk, >but I found sun left permission to blackdown (sure, any other take it >from blackdown) to redistribuite it. So I decide to reopen my ITP on >jdk1.3 and opennms under Dan White <[EMAIL PROTECTED]>'s >suggestion. You and any other can read this things on >http://www.blackdown.org. But the link I just quoted featured a Blackdown developer stating that this was no longer a problem and the Debian jdk maintainer saying that he would package it. What's happening with the jdk maintainership? -- Colin Watson [EMAIL PROTECTED]
Re: Summary of the id?as.
On Wed, Sep 19, 2001 at 11:03:50AM +1000, Jeff Turner wrote: > On Tue, Sep 18, 2001 at 02:44:00PM +0200, Ola Lundqvist wrote: > > To discuss: > > --- > > > > * Should we allow library packages to provide different versions? > > Like libxalan2 that provides both xalan1 and xalan2 jars. > > * Should there be a script that automaticly fixes the symbolic > > links in the /usr/share/java directory. > > * Must programs also place their files in /usr/share/java. > > I'd have thought program-specific jars are by definition, not shared, > and therefore do not belong on /usr/share? /usr/share is for files that can be shared among machines (of different architectures), not necessarily for files that can be shared among programs. I can imagine some packagers preferring to put .jar files that only they care about into /usr/share/ rather than /usr/share/java, though, to keep the namespace clean. > > Default classpath: > > -- > > > > * This discusses the default classpath, except the classpath that > > are needed by the jvm. Should there be any such thing? > > Or rather, *can* any such thing exist without: > > - breaking non-packaged programs which assume a clean classpath. > - upsetting a lot of developers who like to make a clean-classpath >assumption. I think most Apache coders fall into this category, >because most (all?) Apache projects ignore the classpath, and use an >Ant properties file to find jars. Perhaps other Apache people to Marcus Crafter> can confirm/deny this. I think there's got to be some kind of default classpath, even if it can be overridden, otherwise programs without a startup script require the user to set an environment variable before they can be used (see Debian policy 10.9: "A program must not depend on environment variables to get reasonable defaults"). -- Colin Watson [EMAIL PROTECTED]
Re: Summary of the id?as.
On Wed, Sep 19, 2001 at 11:23:35PM +0200, Ola Lundqvist wrote: > On Wed, Sep 19, 2001 at 02:08:03PM -0500, Colin Watson wrote: > > I think there's got to be some kind of default classpath, even if it can > > be overridden, otherwise programs without a startup script require the > > user to set an environment variable before they can be used (see Debian > > policy 10.9: "A program must not depend on environment variables to get > > reasonable defaults"). > > Well the java policy says that all java programs must have a startup > script. 'java' is a program too, though, isn't it? -- Colin Watson [EMAIL PROTECTED]
Re: Summary of the id?as.
On Wed, Sep 19, 2001 at 06:15:32PM -0700, Rob Helmer wrote: > > > Well the java policy says that all java programs must have a startup > > > script. > > > > 'java' is a program too, though, isn't it? > > Nope : > > [EMAIL PROTECTED] 6:14pm ~ >cat `which java` | head > #!/bin/sh Yep, looks like a program to me, at least as far as Debian policy is concerned where it says that the user shouldn't have to set special environment variables. I'm just pointing out that some kind of default classpath is required by that policy. Oh, hang on. The original post said: > * This discusses the default classpath, except the classpath that > are needed by the jvm. ... so perhaps I've missed the point. I'll get my coat. -- Colin Watson [EMAIL PROTECTED]
Re: j2* files from incoming
On Fri, Sep 28, 2001 at 02:17:40PM -0600, J. R. Westmoreland wrote: > So > What am I doing wrong? > I try to go to incoming.debian.org with http to download the j2sdk etc > and get the message that says can't connect to site. > Is this the correct site? The machine that hosts incoming is down for maintenance, which didn't go as planned. According to Ben, it won't be back up until some time today. -- Colin Watson [EMAIL PROTECTED]
Re: Blackdown Java 2 copyright (j2sdk, j2se)
On Sun, Oct 07, 2001 at 08:44:27PM +0200, Henning Makholm wrote: > Scripsit James Troup <[EMAIL PROTECTED]> > > One interesting thing I did see was in the Sun Supplemental License > > terms, point 2: > > > | (iii) you do not distribute additional software intended to replace > > | any component(s) of the Software > > > Since we actually do this[1] albeit not in the same package, does this > > disqualify us from putting it in non-free? > > Sun would probably think so. Thus it does. I was under the impression from the discussions this spring that the Blackdown folks had got explicit permission from Sun for Debian to distribute the JDK in non-free. Somebody on -java is likely to know for sure. -- Colin Watson [EMAIL PROTECTED]
Re: java2-*-dummy packages rejected
On Tue, Oct 23, 2001 at 11:53:39AM +0200, Marcus Crafter wrote: > What happens now ? According to the URL above, the dummy > packages can't be installed into 'main' because they can only be > satisfied by non-free packages - can we install the dummy > packages into non-free then ? The dummy packages could go into contrib. This means free packages depending on them would have to go into contrib too, but without a free Java 2 system they'd have to anyway so that shouldn't be a problem. -- Colin Watson [EMAIL PROTECTED]
Re: Summary of the id?as.
On Fri, Nov 02, 2001 at 01:06:54AM -0600, Adam Heath wrote: > Also, it may be beneficial for java-common to register .jar/.war/.ear > files with /proc/sys/fs/binfmt_misc, and provide a wrapper script for > running these. This could keep each binary package from having to have > its own wrapper script, in addition to improving the usability of java > in debian. binfmt-support was written with this in mind. I never uploaded the Java wrapper part of it because the way Java works got ahead of me, but it should still be done. Somebody please poke me until I fix the shortcoming mentioned in bug #89386, then java-common can use it. > > Checking the jvm: > > = > > > > There must be some mechanism to check which jvm that are > > currently running. And a easy way to select a good jvm. To > > me it seems that we should add a option to the java-wrapper > > to allow this, or? > > java --flavor > > I did not choose -version, as some jvms already have that. --flavor has a > a high probability of not currently being used. Confusing interaction with UK spelling. --variant? --simple-version-string? -- Colin Watson [EMAIL PROTECTED]
Re: STOP INCLUDING EXTERNAL JARS IN YOUR JAVA PACKAGES!
On Sat, Nov 10, 2001 at 12:39:48PM +1100, Jeff Turner wrote: > On Fri, Nov 09, 2001 at 02:05:17PM -0600, Adam Heath wrote: > > Additionally, if libbar-1.1.3 breaks apps that that use > > libbar-1.1.0, then libbar-1.1.3 is broken. Please read the docs sun > > has on the subject(they are very concerned about never breaking > > backwards compatibility). > > How about when libbar-2.0 comes along, and justifiably breaks > backwards-compatibility? Must we not use all apps relying on libbar-1.x, > until they upgrade? Shared library versioning solved this problem long ago. libc5 and libc6 can coexist in the same system. You just package .jars that break backward compatibility with a new package name. > Also, Java has hierarchical classloaders, which allow multiple > incompatible versions of classes to be loaded into the same JVM. Take > Tomcat 3.3 and 4.0 for example. Tomcat uses JAXP 1.1 and Crimson, but > webapps are free to use any incompatible jars they like (a hypothetical > JAXP 2.0, for instance). So assuming a perfect world where everything is > in a .deb, Tomcat requires libjaxp-1.1, my webapp requires libjaxp-2.0, > and there's no conflict. > > We're not in Kansas anymore, Toto :) The old rules don't always apply. I got the impression that Adam was upset at least partly about the legal issues. -- Colin Watson [EMAIL PROTECTED]
Re: Architecture question
On Tue, Nov 13, 2001 at 08:57:35AM -0600, Ben Burton wrote: > Hi. Packages libeditline-java and libreadline-java won't build on > ia64/m68k which AFAICT have no java complier at all in main. I can't > make them architecture: all since they contain compiled JNI modules. Personally I'd leave the Architecture: line alone. I don't think it's a package's responsibility to track the architectures on which its dependencies are available. The buildds have a 'dep-wait' state which (AIUI) represents this. > Anyway, I'd like thoughts/suggestions, because otherwise these > packages will never make it into testing, which means jython will > never make it into testing (which is what concerns me more). Are you sure? I believe that testing only cares about binaries being out of date on various architectures; if they simply aren't compiled on those architectures, it doesn't matter. -- Colin Watson [EMAIL PROTECTED]
Re: request for bug filing on all packages uses /usr/share/java/repository
On Fri, Jan 04, 2002 at 07:12:29PM +0100, Ola Lundqvist wrote: > On Fri, Dec 28, 2001 at 11:43:54AM -0600, Colin Watson wrote: > > Amid all the arguments I've lost track of exactly why > > /usr/share/java/repository causes a problem for building things. Can > > somebody explain to me why it's worse than, say, /usr/include or > > /usr/lib? > > The lack of versioning support is the problem. One other problem is that > the hader definition and implementation are located on the same place. > It is the same as if /usr/lib and /usr/include was located in the same > place. OK. I now see why it applies to libraries, but don't see why it's a benefit for standalone programs (where multiple versions can't be installed via dpkg simultaneously anyway, and where the .jars aren't intended for external use). I suppose it's a little neater. Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: Re: Java or C/C++
On Fri, Jan 11, 2002 at 01:50:04PM -0800, [EMAIL PROTECTED] wrote: > Could software created using Java be released under the GPL? Yes. See http://www.gnu.org/software/java/java.html. -- Colin Watson [EMAIL PROTECTED]
Re: Backtrace
tags 123041 patch
thanks
On Sun, Feb 17, 2002 at 04:06:37AM +, Colin Watson wrote:
> This is a 64-bit issue; jikes assumes that sizeof(int) == sizeof(void*),
> which isn't true on alpha or ia64. Specifically, in src/ast.h it tries
> to declare objects of type AstArray, where
> LexStream::TokenIndex is a typedef for int. I'll try to track this down
> some more tomorrow, but in the meantime here's a gdb backtrace.
This patch fixes - or at least works around - the problem. While I don't
think it's guaranteed by the C(++) standard that sizeof(long) ==
sizeof(void*), it's true on all architectures we're releasing with
woody. Upstream should work out something that uses a real pointer, but
that's more than I care to try to do as somebody with no experience of
hacking jikes. I've left the LEX_INFINITY constant as it is, as values
of TokenIndex will very likely be assigned to int types at various
points.
With this patch applied, jikes builds successfully on alpha and i386,
and generates code that's byte-for-byte identical with its output
without the patch both for the simple test case I mentioned earlier in
the bug report and for a complete build of antlr.
--- jikes-1.15.orig/src/stream.h
+++ jikes-1.15/src/stream.h
@@ -191,7 +191,7 @@
public:
typedef int TypeIndex;
-typedef int TokenIndex;
+typedef long TokenIndex;
typedef int CommentIndex;
enum { LEX_INFINITY = INT_MAX }; // the largest possible value for
TokenIndex
The last seven uploads of jikes have been NMUs. Since another bug
(#119551) is holding up freenet-unstable, would there be a problem with
me making another one? If so, do debian-java think it would be better to
apply the backport patch mentioned in #119551 or to upgrade wholesale to
the upstream major-bug-fix release mentioned in #133616?
--
Colin Watson [EMAIL PROTECTED]
Re: Backtrace
On Sun, Feb 17, 2002 at 08:57:17PM -0800, Stephen Zander wrote: > >>>>> "Colin" == Colin Watson <[EMAIL PROTECTED]> writes: > Colin> The last seven uploads of jikes have been NMUs. Since > Colin> another bug (#119551) is holding up freenet-unstable, would > Colin> there be a problem with me making another one? If so, do > Colin> debian-java think it would be better to apply the backport > Colin> patch mentioned in #119551 or to upgrade wholesale to the > Colin> upstream major-bug-fix release mentioned in #133616? I've since discovered that said release (1.15b) also fixes bug #123041. > Adam Majer <[EMAIL PROTECTED]> filed an ITA on jikes, have > you asked him what he intends? Ack, I didn't notice jikes was in the process of being adopted. My bad. Adam? > If he's not going to come through on the ITA, let me know & I'll take > the package over (assuming I can having seen Sun's java source at some > time since the big bang). > > I'd argue for going the wholesale upgrade route. Yes, that seems more than reasonable at this point. -- Colin Watson [EMAIL PROTECTED]
Re: CLASSPATH and Jikes
On Sat, Mar 30, 2002 at 12:04:29PM +0100, Robert Bihlmeyer wrote: > Another way is to provide small scripts jikes-kaffe, jikes-ibm, > jikes-sun, etc. and make /usr/bin/jikes handled by > update-alternatives. This would make it consistent with how > /usr/bin/java is currently handled. (Perhaps the default could even be > determined by looking at the java alternative.) That sounds like it would work better with autobuilders, too - you could build-depend on jikes (>= foo), invoke jikes-kaffe, and expect it to work everywhere. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#90243: ITP: jdk1.3 -- Java Development Kit
Maurizio Boriani <[EMAIL PROTECTED]> wrote: >On Mon, Mar 19, 2001 at 10:09:31AM +0000, Colin Watson wrote: >> Maurizio Boriani <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: >> >Package: wnpp >> >Severity: wishlist >> >URL: ftp://ftp.progsoc.uts.edu.au/pub/Linux/java/JDK-1.3.0/ >> > >> >This is Sun Java Development kit from blackdown. Sun permit this version >> >redistribution unlike sun download ftp server. >> >> Um, in http://lists.debian.org/debian-java-0103/msg00091.html Stephen >> Zander (jdk1.1 maintainer) said he was going to package this now that >> the legalities have been sorted out ... have I missed something? > >This legalities was denied for any other to redistribuite jdk, >but I found sun left permission to blackdown (sure, any other take it >from blackdown) to redistribuite it. So I decide to reopen my ITP on >jdk1.3 and opennms under Dan White <[EMAIL PROTECTED]>'s >suggestion. You and any other can read this things on >http://www.blackdown.org. But the link I just quoted featured a Blackdown developer stating that this was no longer a problem and the Debian jdk maintainer saying that he would package it. What's happening with the jdk maintainership? -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java2-*-dummy packages rejected
On Tue, Oct 23, 2001 at 11:53:39AM +0200, Marcus Crafter wrote: > What happens now ? According to the URL above, the dummy > packages can't be installed into 'main' because they can only be > satisfied by non-free packages - can we install the dummy > packages into non-free then ? The dummy packages could go into contrib. This means free packages depending on them would have to go into contrib too, but without a free Java 2 system they'd have to anyway so that shouldn't be a problem. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Summary of the id?as.
On Fri, Nov 02, 2001 at 01:06:54AM -0600, Adam Heath wrote: > Also, it may be beneficial for java-common to register .jar/.war/.ear > files with /proc/sys/fs/binfmt_misc, and provide a wrapper script for > running these. This could keep each binary package from having to have > its own wrapper script, in addition to improving the usability of java > in debian. binfmt-support was written with this in mind. I never uploaded the Java wrapper part of it because the way Java works got ahead of me, but it should still be done. Somebody please poke me until I fix the shortcoming mentioned in bug #89386, then java-common can use it. > > Checking the jvm: > > = > > > > There must be some mechanism to check which jvm that are > > currently running. And a easy way to select a good jvm. To > > me it seems that we should add a option to the java-wrapper > > to allow this, or? > > java --flavor > > I did not choose -version, as some jvms already have that. --flavor has a > a high probability of not currently being used. Confusing interaction with UK spelling. --variant? --simple-version-string? -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: STOP INCLUDING EXTERNAL JARS IN YOUR JAVA PACKAGES!
On Sat, Nov 10, 2001 at 12:39:48PM +1100, Jeff Turner wrote: > On Fri, Nov 09, 2001 at 02:05:17PM -0600, Adam Heath wrote: > > Additionally, if libbar-1.1.3 breaks apps that that use > > libbar-1.1.0, then libbar-1.1.3 is broken. Please read the docs sun > > has on the subject(they are very concerned about never breaking > > backwards compatibility). > > How about when libbar-2.0 comes along, and justifiably breaks > backwards-compatibility? Must we not use all apps relying on libbar-1.x, > until they upgrade? Shared library versioning solved this problem long ago. libc5 and libc6 can coexist in the same system. You just package .jars that break backward compatibility with a new package name. > Also, Java has hierarchical classloaders, which allow multiple > incompatible versions of classes to be loaded into the same JVM. Take > Tomcat 3.3 and 4.0 for example. Tomcat uses JAXP 1.1 and Crimson, but > webapps are free to use any incompatible jars they like (a hypothetical > JAXP 2.0, for instance). So assuming a perfect world where everything is > in a .deb, Tomcat requires libjaxp-1.1, my webapp requires libjaxp-2.0, > and there's no conflict. > > We're not in Kansas anymore, Toto :) The old rules don't always apply. I got the impression that Adam was upset at least partly about the legal issues. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Architecture question
On Tue, Nov 13, 2001 at 08:57:35AM -0600, Ben Burton wrote: > Hi. Packages libeditline-java and libreadline-java won't build on > ia64/m68k which AFAICT have no java complier at all in main. I can't > make them architecture: all since they contain compiled JNI modules. Personally I'd leave the Architecture: line alone. I don't think it's a package's responsibility to track the architectures on which its dependencies are available. The buildds have a 'dep-wait' state which (AIUI) represents this. > Anyway, I'd like thoughts/suggestions, because otherwise these > packages will never make it into testing, which means jython will > never make it into testing (which is what concerns me more). Are you sure? I believe that testing only cares about binaries being out of date on various architectures; if they simply aren't compiled on those architectures, it doesn't matter. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: j2* files from incoming
On Fri, Sep 28, 2001 at 02:17:40PM -0600, J. R. Westmoreland wrote: > So > What am I doing wrong? > I try to go to incoming.debian.org with http to download the j2sdk etc > and get the message that says can't connect to site. > Is this the correct site? The machine that hosts incoming is down for maintenance, which didn't go as planned. According to Ben, it won't be back up until some time today. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: request for bug filing on all packages uses /usr/share/java/repository
On Thu, Dec 06, 2001 at 07:28:19PM -0600, Adam Heath wrote: > Can I do the above? It's just so crappily wrong to have this, it > should have never existed, the person(s) who thought it up should be > flambayed(sp). > > I WANT to remove ALL traces of this from ALL packages, NOW. It makes > building oh so difficult. Amid all the arguments I've lost track of exactly why /usr/share/java/repository causes a problem for building things. Can somebody explain to me why it's worse than, say, /usr/include or /usr/lib? I've just converted jlex to using a .jar rather than the repository, anyway, although I can't really see any particular benefits one way or the other for a standalone program like this. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: request for bug filing on all packages uses /usr/share/java/repository
On Fri, Jan 04, 2002 at 07:12:29PM +0100, Ola Lundqvist wrote: > On Fri, Dec 28, 2001 at 11:43:54AM -0600, Colin Watson wrote: > > Amid all the arguments I've lost track of exactly why > > /usr/share/java/repository causes a problem for building things. Can > > somebody explain to me why it's worse than, say, /usr/include or > > /usr/lib? > > The lack of versioning support is the problem. One other problem is that > the hader definition and implementation are located on the same place. > It is the same as if /usr/lib and /usr/include was located in the same > place. OK. I now see why it applies to libraries, but don't see why it's a benefit for standalone programs (where multiple versions can't be installed via dpkg simultaneously anyway, and where the .jars aren't intended for external use). I suppose it's a little neater. Thanks, -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Java or C/C++
On Fri, Jan 11, 2002 at 01:50:04PM -0800, [EMAIL PROTECTED] wrote: > Could software created using Java be released under the GPL? Yes. See http://www.gnu.org/software/java/java.html. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Backtrace
tags 123041 patch
thanks
On Sun, Feb 17, 2002 at 04:06:37AM +, Colin Watson wrote:
> This is a 64-bit issue; jikes assumes that sizeof(int) == sizeof(void*),
> which isn't true on alpha or ia64. Specifically, in src/ast.h it tries
> to declare objects of type AstArray, where
> LexStream::TokenIndex is a typedef for int. I'll try to track this down
> some more tomorrow, but in the meantime here's a gdb backtrace.
This patch fixes - or at least works around - the problem. While I don't
think it's guaranteed by the C(++) standard that sizeof(long) ==
sizeof(void*), it's true on all architectures we're releasing with
woody. Upstream should work out something that uses a real pointer, but
that's more than I care to try to do as somebody with no experience of
hacking jikes. I've left the LEX_INFINITY constant as it is, as values
of TokenIndex will very likely be assigned to int types at various
points.
With this patch applied, jikes builds successfully on alpha and i386,
and generates code that's byte-for-byte identical with its output
without the patch both for the simple test case I mentioned earlier in
the bug report and for a complete build of antlr.
--- jikes-1.15.orig/src/stream.h
+++ jikes-1.15/src/stream.h
@@ -191,7 +191,7 @@
public:
typedef int TypeIndex;
-typedef int TokenIndex;
+typedef long TokenIndex;
typedef int CommentIndex;
enum { LEX_INFINITY = INT_MAX }; // the largest possible value for TokenIndex
The last seven uploads of jikes have been NMUs. Since another bug
(#119551) is holding up freenet-unstable, would there be a problem with
me making another one? If so, do debian-java think it would be better to
apply the backport patch mentioned in #119551 or to upgrade wholesale to
the upstream major-bug-fix release mentioned in #133616?
--
Colin Watson [[EMAIL PROTECTED]]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Backtrace
On Sun, Feb 17, 2002 at 08:57:17PM -0800, Stephen Zander wrote: > >>>>> "Colin" == Colin Watson <[EMAIL PROTECTED]> writes: > Colin> The last seven uploads of jikes have been NMUs. Since > Colin> another bug (#119551) is holding up freenet-unstable, would > Colin> there be a problem with me making another one? If so, do > Colin> debian-java think it would be better to apply the backport > Colin> patch mentioned in #119551 or to upgrade wholesale to the > Colin> upstream major-bug-fix release mentioned in #133616? I've since discovered that said release (1.15b) also fixes bug #123041. > Adam Majer <[EMAIL PROTECTED]> filed an ITA on jikes, have > you asked him what he intends? Ack, I didn't notice jikes was in the process of being adopted. My bad. Adam? > If he's not going to come through on the ITA, let me know & I'll take > the package over (assuming I can having seen Sun's java source at some > time since the big bang). > > I'd argue for going the wholesale upgrade route. Yes, that seems more than reasonable at this point. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CLASSPATH and Jikes
On Sat, Mar 30, 2002 at 12:04:29PM +0100, Robert Bihlmeyer wrote: > Another way is to provide small scripts jikes-kaffe, jikes-ibm, > jikes-sun, etc. and make /usr/bin/jikes handled by > update-alternatives. This would make it consistent with how > /usr/bin/java is currently handled. (Perhaps the default could even be > determined by looking at the java alternative.) That sounds like it would work better with autobuilders, too - you could build-depend on jikes (>= foo), invoke jikes-kaffe, and expect it to work everywhere. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dynamic Text in package descriptions
On Fri, Aug 19, 2011 at 01:28:59PM +0100, Jonathan Wiltshire wrote: > On Fri, Aug 19, 2011 at 02:11:27PM +0200, Michael Bramer wrote: > > - This make extra load for the translation of this description. > > It does and for that reason I'm including debian-i18n in this discussion. > For the record I support the idea that dynamic descriptions should be > discouraged unless there is a sound technical reason. It may well also cause problems for multiarch. apt supports moving long descriptions to an architecture-independent Translations-en file, which makes it significantly more bandwidth-efficient to download Packages files for multiple architectures. Obviously this only works correctly if descriptions are identical across architectures (which is, fortunately, mostly true). -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110819140615.gb8...@riva.dynamic.greenend.org.uk
