Hi all,
There is a program i would like to package (josm), only it doesn't compile with gcj, but it does with icedtea. Can this go into fedora?
Regards, Sander
Sander Hoentjen writes:
There is a program i would like to package (josm), only it doesn't compile with gcj, but it does with icedtea. Can this go into fedora?
It would be better to avoid that. Why won't it compile with gcj?
Andrew.
On Sun, 2007-11-25 at 16:55 +0000, Andrew Haley wrote:
Sander Hoentjen writes:
There is a program i would like to package (josm), only it doesn't compile with gcj, but it does with icedtea. Can this go into fedora?
It would be better to avoid that. Why won't it compile with gcj?
The method getMousePosition() is undefined for the type Component So.. how much better is it to avoid it? Do I have to patch the whole program to not use that function (I don't know if I can do it), or should I just go for icedtea?
Sander
Sander Hoentjen writes:
On Sun, 2007-11-25 at 16:55 +0000, Andrew Haley wrote:
Sander Hoentjen writes:
There is a program i would like to package (josm), only it doesn't compile with gcj, but it does with icedtea. Can this go into fedora?
It would be better to avoid that. Why won't it compile with gcj?
The method getMousePosition() is undefined for the type Component So.. how much better is it to avoid it? Do I have to patch the whole program to not use that function (I don't know if I can do it), or should I just go for icedtea?
Ah, okay, this is a method that is new since Java 1.5.
While we can make your package depend on IcedTea if there is absolutely no way to avoid doing so, it would be better either to fix libgcj or to fix your program so as to avoid getMousePosition(). Fixing libgcj looks pretty trivial: Component.getMousePosition() simply calls MouseInfo.getPointerInfo() and adjusts the info relative to the co-ordinates of its own window.
Calling Classpath AWT mainatainers: can anyone catch this?
Thanks, Andrew.
Hi,
* Sander Hoentjen sander@hoentjen.eu [2007-11-25 09:37]:
There is a program i would like to package (josm), only it doesn't compile with gcj, but it does with icedtea. Can this go into fedora?
Ideally things would build with gcj and be usable on all arches, but I don't think Fedora has a policy of excluding IcedTea-only packages. Does anyone know if we've come up with a policy?
Andrew
Andrew Overholt writes:
Hi,
- Sander Hoentjen sander@hoentjen.eu [2007-11-25 09:37]:
There is a program i would like to package (josm), only it doesn't compile with gcj, but it does with icedtea. Can this go into fedora?
Ideally things would build with gcj and be usable on all arches, but I don't think Fedora has a policy of excluding IcedTea-only packages. Does anyone know if we've come up with a policy?
We shouldn't need one. Lat's first try to find out what the problem actually is.
Andrew.
Sander Hoentjen wrote:
Hi all,
There is a program i would like to package (josm), only it doesn't compile with gcj, but it does with icedtea. Can this go into fedora?
During the Fedora 8 Features FESCo meeting, the issue of build requiring IcedTea came up. The informal policy decision was that packages may build require IcedTea, but must still run on the base Fedora architectures (i386, x86_64, ppc, ppc64) without requiring external packages. For Fedora 8, that meant packages had to run on ppc/ppc64 libgcj. For Fedora 9, IcedTea's ppc/ppc64 interpreter should suffice. So while ideally the package would build on both, pragmatically I'd say go ahead and build require IcedTea.
Tom
Thomas Fitzsimmons writes:
Sander Hoentjen wrote:
Hi all,
There is a program i would like to package (josm), only it doesn't compile with gcj, but it does with icedtea. Can this go into fedora?
During the Fedora 8 Features FESCo meeting, the issue of build requiring IcedTea came up. The informal policy decision was that packages may build require IcedTea, but must still run on the base Fedora architectures (i386, x86_64, ppc, ppc64) without requiring external packages. For Fedora 8, that meant packages had to run on ppc/ppc64 libgcj. For Fedora 9, IcedTea's ppc/ppc64 interpreter should suffice. So while ideally the package would build on both, pragmatically I'd say go ahead and build require IcedTea.
I understand that, but it would surely be better in this case to get the fix into libgcj. It's not particularly difficult to do, and surely we can be allowed the short time it would take to get the fix in, and then the package would run everywhere. Sure, it's tempting to take the easy road, but in this case it's not hugely difficult to do the right thing.
Andrew.
Andrew Haley wrote:
Thomas Fitzsimmons writes:
Sander Hoentjen wrote:
Hi all,
There is a program i would like to package (josm), only it doesn't compile with gcj, but it does with icedtea. Can this go into fedora?
During the Fedora 8 Features FESCo meeting, the issue of build requiring IcedTea came up. The informal policy decision was that packages may build require IcedTea, but must still run on the base Fedora architectures (i386, x86_64, ppc, ppc64) without requiring external packages. For Fedora 8, that meant packages had to run on ppc/ppc64 libgcj. For Fedora 9, IcedTea's ppc/ppc64 interpreter should suffice. So while ideally the package would build on both, pragmatically I'd say go ahead and build require IcedTea.
I understand that, but it would surely be better in this case to get the fix into libgcj. It's not particularly difficult to do, and surely we can be allowed the short time it would take to get the fix in, and then the package would run everywhere. Sure, it's tempting to take the easy road, but in this case it's not hugely difficult to do the right thing.
Yes, I'm working on a fix for GNU Classpath. However, understand that it does take a non-trivial amount of time to get a libgcj fix into Fedora, through the GNU Classpath -> gcc HEAD -> Red Hat gcc branch -> Fedora Rawhide chain -- several days at a minimum. I'd rather not hold up Sander's progress waiting for the fix to land.
Tom
On Mon, 2007-11-26 at 15:09 -0500, Thomas Fitzsimmons wrote:
Andrew Haley wrote:
Thomas Fitzsimmons writes:
Sander Hoentjen wrote:
Hi all,
There is a program i would like to package (josm), only it doesn't compile with gcj, but it does with icedtea. Can this go into fedora?
During the Fedora 8 Features FESCo meeting, the issue of build requiring IcedTea came up. The informal policy decision was that packages may build require IcedTea, but must still run on the base Fedora architectures (i386, x86_64, ppc, ppc64) without requiring external packages. For Fedora 8, that meant packages had to run on ppc/ppc64 libgcj. For Fedora 9, IcedTea's ppc/ppc64 interpreter should suffice. So while ideally the package would build on both, pragmatically I'd say go ahead and build require IcedTea.
I understand that, but it would surely be better in this case to get the fix into libgcj. It's not particularly difficult to do, and surely we can be allowed the short time it would take to get the fix in, and then the package would run everywhere. Sure, it's tempting to take the easy road, but in this case it's not hugely difficult to do the right thing.
Yes, I'm working on a fix for GNU Classpath. However, understand that it does take a non-trivial amount of time to get a libgcj fix into Fedora, through the GNU Classpath -> gcc HEAD -> Red Hat gcc branch -> Fedora Rawhide chain -- several days at a minimum. I'd rather not hold up Sander's progress waiting for the fix to land.
Thanks for your concern, but for me it is no problem. Tomorrow I will go ahead and submit the package for review. It will probably take some time before it is approved anyway. The question that remains is will this fix ever go into F8, if not I would still have a problem.
I do like this solution better, so again I can be patient.
Sander
Thomas Fitzsimmons writes:
Andrew Haley wrote:
Thomas Fitzsimmons writes:
Sander Hoentjen wrote:
Hi all,
There is a program i would like to package (josm), only it doesn't compile with gcj, but it does with icedtea. Can this go into fedora?
During the Fedora 8 Features FESCo meeting, the issue of build requiring IcedTea came up. The informal policy decision was that packages may build require IcedTea, but must still run on the base Fedora architectures (i386, x86_64, ppc, ppc64) without requiring external packages. For Fedora 8, that meant packages had to run on ppc/ppc64 libgcj. For Fedora 9, IcedTea's ppc/ppc64 interpreter should suffice. So while ideally the package would build on both, pragmatically I'd say go ahead and build require IcedTea.
I understand that, but it would surely be better in this case to get the fix into libgcj. It's not particularly difficult to do, and surely we can be allowed the short time it would take to get the fix in, and then the package would run everywhere. Sure, it's tempting to take the easy road, but in this case it's not hugely difficult to do the right thing.
Yes, I'm working on a fix for GNU Classpath. However, understand that it does take a non-trivial amount of time to get a libgcj fix into Fedora, through the GNU Classpath -> gcc HEAD -> Red Hat gcc branch -> Fedora Rawhide chain -- several days at a minimum. I'd rather not hold up Sander's progress waiting for the fix to land.
OK, that's fair, but it's going to be *really* easy to let things in Classpath slide. I am going to keep on top of this: apart from ppc issues, there are also the secondary architectures ARM, IA-64, and SPARC. I'd like to keep gcj going in good shape until we have a reasonable portability story for OpenJDK.
Andrew.
Il giorno mar, 27/11/2007 alle 10.35 +0000, Andrew Haley ha scritto:
OK, that's fair, but it's going to be *really* easy to let things in Classpath slide. I am going to keep on top of this: apart from ppc issues, there are also the secondary architectures ARM, IA-64, and SPARC. I'd like to keep gcj going in good shape until we have a reasonable portability story for OpenJDK.
Andrew.
+1 if that matter
Mario
Andrew Haley writes:
OK, that's fair, but it's going to be *really* easy to let things in Classpath slide. I am going to keep on top of this: apart from ppc issues, there are also the secondary architectures ARM, IA-64, and SPARC. I'd like to keep gcj going in good shape until we have a reasonable portability story for OpenJDK.
One small thing to add: I'm not really sure that a slow interpreter is all we need for secondary arches. For some things it'll be perfectly OK, but not for others. We'll have to wait and see what people need.
Andrew.
java-devel@lists.fedoraproject.org