Fedora java packaging, icedtea vs gcj

[Sander Hoentjen]

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

[Andrew Haley]

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.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Sander Hoentjen]

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

[Andrew Haley]

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.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Andrew Overholt]

Hi,

* Sander Hoentjen <sander(a)hoentjen.eu&gt; [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 Haley]

Andrew Overholt writes:
>  Hi,
>  
>  * Sander Hoentjen <sander(a)hoentjen.eu&gt; [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.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Thomas Fitzsimmons]

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

[Andrew Haley]

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.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Thomas Fitzsimmons]

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

[Sander Hoentjen]

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

[Andrew Haley]

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.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Mario Torre]

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
-- 
Lima Software - http://www.limasoftware.net/
GNU Classpath Developer - http://www.classpath.org/
Fedora Ambassador - http://fedoraproject.org/wiki/MarioTorre
Jabber: neugens(a)jabber.org
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/

[Andrew Haley]

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.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903