FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 02-28-2010, 01:39 PM
Henrique Junior
 
Default Impasse on packaging JOGL and Gluegen

Hi, gentlemen,

For
some time the inclusion of the software Scilab [1] in our repos has been barred
by various dependencies, which were being resolved with time.¬*Currently, the biggest reason we do not have this
software in our repos is that it relies in a software called JOGL [2].

The
big question here is that JOGL, in his turn, depends on other software called
Gluegen [3] and, more specifically, it depends on the **source tree** of
Gluegen, as explained in the instructions for build [4]:




"Step
5 - Check out the GlueGen source tree:

JOGL
GlueGen relies on the project to autogenerate most of the Java and JNI code for
the OpenGL interface.¬*The JOGL / and gluegen /
workspaces must be side-by-side in order for JOGL to build properly. "




At
this stage, we have drafts of packages for both, Gluegen [5] and JOGL [6], but
we got to the stalemate that JOGL continues to need Gluegen’s **code** to build
his own build.xml, so, even if we have Gluegen packaged and installed, what
matters for the correct build of JOGL is the gluegen’s code side by side.

At
first I thought it would be better to generate both packages from a single .spec,
then I decided to create a separate package for Gluegen and provide a tarball
of that Gluegen’s code as Source1 for the compilation of JOGL.

As
Chen Lei said, the fact that JOGL needs this code may mean that it will be blocked
forever for packaging, but I do not particularly see a big problem.

For
more details, please, read the log in bugzilla and give your ideas regarding
this question.





[1] -
http://www.scilab.org/

[2] - https: / / jogl.dev.java.net /

[3] - https: / /
gluegen.dev.java.net /

[4] -
http://download.java.net/media/jogl/doc/HowToBuild.html

[5] - https: /
/ bugzilla.redhat.com / show_bug.cgi? Id = 439627

[6] - https: /
/ bugzilla.redhat.com / show_bug.cgi? Id = 439630
¬*------------------------------
Henrique "LonelySpooky" Junior







Veja quais s√£o os assuntos do momento no Yahoo! + Buscados: Top 10 - Celebridades - M√ļsica - Esportes--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-28-2010, 01:39 PM
Henrique Junior
 
Default Impasse on packaging JOGL and Gluegen

Hi, gentlemen,

For
some time the inclusion of the software Scilab [1] in our repos has been barred
by various dependencies, which were being resolved with time.¬*Currently, the biggest reason we do not have this
software in our repos is that it relies in a software called JOGL [2].

The
big question here is that JOGL, in his turn, depends on other software called
Gluegen [3] and, more specifically, it depends on the **source tree** of
Gluegen, as explained in the instructions for build [4]:




"Step
5 - Check out the GlueGen source tree:

JOGL
GlueGen relies on the project to autogenerate most of the Java and JNI code for
the OpenGL interface.¬*The JOGL / and gluegen /
workspaces must be side-by-side in order for JOGL to build properly. "




At
this stage, we have drafts of packages for both, Gluegen [5] and JOGL [6], but
we got to the stalemate that JOGL continues to need Gluegen’s **code** to build
his own build.xml, so, even if we have Gluegen packaged and installed, what
matters for the correct build of JOGL is the gluegen’s code side by side.

At
first I thought it would be better to generate both packages from a single .spec,
then I decided to create a separate package for Gluegen and provide a tarball
of that Gluegen’s code as Source1 for the compilation of JOGL.

As
Chen Lei said, the fact that JOGL needs this code may mean that it will be blocked
forever for packaging, but I do not particularly see a big problem.

For
more details, please, read the log in bugzilla and give your ideas regarding
this question.





[1] -
http://www.scilab.org/

[2] - https: / / jogl.dev.java.net /

[3] - https: / /
gluegen.dev.java.net /

[4] -
http://download.java.net/media/jogl/doc/HowToBuild.html

[5] - https: /
/ bugzilla.redhat.com / show_bug.cgi? Id = 439627

[6] - https: /
/ bugzilla.redhat.com / show_bug.cgi? Id = 439630
¬*------------------------------
Henrique "LonelySpooky" Junior







Veja quais s√£o os assuntos do momento no Yahoo! + Buscados: Top 10 - Celebridades - M√ļsica - Esportes--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-28-2010, 01:49 PM
Hans de Goede
 
Default Impasse on packaging JOGL and Gluegen

Hi,

On 02/28/2010 03:39 PM, Henrique Junior wrote:
> Hi, gentlemen,
> For some time the inclusion of the software Scilab [1] in our repos has
> been barred by various dependencies, which were being resolved with
> time. Currently, the biggest reason we do not have this software in our
> repos is that it relies in a software called JOGL [2].
> The big question here is that JOGL, in his turn, depends on other
> software called Gluegen [3] and, more specifically, it depends on the
> **source tree** of Gluegen, as explained in the instructions for build [4]:
>
>
> "Step 5 - Check out the GlueGen source tree:
> JOGL GlueGen relies on the project to autogenerate most of the Java and
> JNI code for the OpenGL interface. The JOGL / and gluegen / workspaces
> must be side-by-side in order for JOGL to build properly. "
>
>
> At this stage, we have drafts of packages for both, Gluegen [5] and JOGL
> [6], but we got to the stalemate that JOGL continues to need Gluegen’s
> **code** to build his own build.xml, so, even if we have Gluegen
> packaged and installed, what matters for the correct build of JOGL is
> the gluegen’s code side by side.
> At first I thought it would be better to generate both packages from a
> single .spec, then I decided to create a separate package for Gluegen
> and provide a tarball of that Gluegen’s code as Source1 for the
> compilation of JOGL.
> As Chen Lei said, the fact that JOGL needs this code may mean that it
> will be blocked forever for packaging, but I do not particularly see a
> big problem.
> For more details, please, read the log in bugzilla and give your ideas
> regarding this question.
>

AFAIK we have had problems like this before with various bits of Xorg
(iirc) needing the sources of other bits to build.

The "usual" solution for this, is to give a package a -source subpackage,
which contains the extracted sources (and installs them under
/usr/src

So I think the best way to handle this is to package gluegen, and include
gluegen's sources as a gluegen-source subpackage, and then make jogl
BuildRequire gluegen-source.

Regards,

Hans
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-28-2010, 04:22 PM
Toshio Kuratomi
 
Default Impasse on packaging JOGL and Gluegen

On Sun, Feb 28, 2010 at 06:39:43AM -0800, Henrique Junior wrote:
> Hi, gentlemen,
> For some time the inclusion of the software Scilab [1] in our repos has been
> barred by various dependencies, which were being resolved with time. Currently,
> the biggest reason we do not have this software in our repos is that it relies
> in a software called JOGL [2].
> The big question here is that JOGL, in his turn, depends on other software
> called Gluegen [3] and, more specifically, it depends on the **source tree** of
> Gluegen, as explained in the instructions for build [4]:
>
>
> "Step 5 - Check out the GlueGen source tree:
> JOGL GlueGen relies on the project to autogenerate most of the Java and JNI
> code for the OpenGL interface. The JOGL / and gluegen / workspaces must be
> side-by-side in order for JOGL to build properly. "
>
You need to figure out why jogl needs gluegen and what the ramification is
for the final package in order to really get this discussion going. The
closer we can make this to a static library issue, the easier time you'll
have justifying an exception. The closer it is to a bundled library, the
less likely an exception is.

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-28-2010, 08:58 PM
Henrique Junior
 
Default Impasse on packaging JOGL and Gluegen

> You need to figure out why jogl needs gluegen and what the ramification is
> for the final package in order to really get this discussion going. *The
> closer we can make this to a static library issue, the easier time you'll
> have justifying an exception. *The closer it is to a bundled library, the
> less likely an exception is.
>
> -Toshio

I think that Hans's suggestion (in the devel list) may be a good solution.



--
Henrique "LonelySpooky" Junior
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 03-01-2010, 12:22 AM
Kevin Kofler
 
Default Impasse on packaging JOGL and Gluegen

Hans de Goede wrote:
> AFAIK we have had problems like this before with various bits of Xorg
> (iirc) needing the sources of other bits to build.
>
> The "usual" solution for this, is to give a package a -source subpackage,
> which contains the extracted sources (and installs them under
> /usr/src
>
> So I think the best way to handle this is to package gluegen, and include
> gluegen's sources as a gluegen-source subpackage, and then make jogl
> BuildRequire gluegen-source.

Still, this is a very evil workaround. Can JOGL really not be fixed to use
an installed gluegen? Why does it need the source?

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 01:23 AM
"Chen Lei"
 
Default Impasse on packaging JOGL and Gluegen

I think¬*we need some more experienced java packager to accelerate packaging scilab, it can be a new feature for F14.¬*¬*Since scilab¬*may be the best opensource¬*numerical computational software, is there someone interseted in packaging scilab for fedora?
¬*
Regard,
Chen Lei

Śú®2010-03-01¬*09:22:33ÔľĆ"Kevin¬*Kofler"¬*<kevin.kofler@chel lo.at>¬*ŚÜôťĀďÔľö
>Hans¬*de¬*Goede¬*wrote:
>>¬*AFAIK¬*we¬*have¬*had¬*problems¬*like¬*this¬*be fore¬*with¬*various¬*bits¬*of¬*Xorg
>>¬*(iirc)¬*needing¬*the¬*sources¬*of¬*other¬*bits ¬*to¬*build.
>>¬*
>>¬*The¬*"usual"¬*solution¬*for¬*this,¬*is¬*to¬*gi ve¬*a¬*package¬*a¬*-source¬*subpackage,
>>¬*which¬*contains¬*the¬*extracted¬*sources¬*(and ¬*installs¬*them¬*under
>>¬*/usr/src
>>¬*
>>¬*So¬*I¬*think¬*the¬*best¬*way¬*to¬*handle¬*this ¬*is¬*to¬*package¬*gluegen,¬*and¬*include
>>¬*gluegen's¬*sources¬*as¬*a¬*gluegen-source¬*subpackage,¬*and¬*then¬*make¬*jogl
>>¬*BuildRequire¬*gluegen-source.
>
>Still,¬*this¬*is¬*a¬*very¬*evil¬*workaround.¬*Can ¬*JOGL¬*really¬*not¬*be¬*fixed¬*to¬*use¬*
>an¬*installed¬*gluegen?¬*Why¬*does¬*it¬*need¬*the ¬*source?
>
>¬*¬*¬*¬*¬*¬*¬*¬*Kevin¬*Kofler
>
>--¬*
>devel¬*mailing¬*list
>devel@lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/devel


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 01:49 AM
Toshio Kuratomi
 
Default Impasse on packaging JOGL and Gluegen

On Sun, Feb 28, 2010 at 06:58:23PM -0300, Henrique Junior wrote:
> > You need to figure out why jogl needs gluegen and what the ramification is
> > for the final package in order to really get this discussion going. *The
> > closer we can make this to a static library issue, the easier time you'll
> > have justifying an exception. *The closer it is to a bundled library, the
> > less likely an exception is.
> >
> > -Toshio
>
> I think that Hans's suggestion (in the devel list) may be a good solution.
>
Hans's suggestion may be good. But it depends on what is really going on in
jogl. If jogl could be easily patched to not need gluegen's source code but
we end up doing the gluegen source code then it's a very poor solution.
OTOH, if jogl really needs some private "header" from the gluegen source
then it is a resonable solution (it becomes equivalent to tracking a static
library and is an easier exception to grant than an exception for bundled
libraries.)

So... more informaiton is needed.

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 03-01-2010, 01:59 AM
Henrique Junior
 
Default Impasse on packaging JOGL and Gluegen

> Still, this is a very evil workaround. Can JOGL really not be fixed to use
> an installed gluegen? Why does it need the source?

Well, the symbiotic relationship between JOGL and Gluegen is because
the Gluegen project is developed by the JOGL project, in principle,
to be used only by JOGL.

By Wikipedia:
It was originally developed for JOGL, a Java OpenGL library, although
the project has since been separated so it can be used with other
libraries. It is currently also used in JOAL, which allows Java code
to access OpenAL libraries.
In the case of JOGL, GlueGen is not only used to bind OpenGL to Java,
but also the low-level windowing system APIs on the Windows, X11 and
Mac OS X platforms.




--
Henrique "LonelySpooky" Junior
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 02:00 AM
Henrique Junior
 
Default Impasse on packaging JOGL and Gluegen

2010/2/28 Chen Lei <supercyper@163.com>:
> I think*we need some more experienced java packager to accelerate packaging
> scilab, it can be a new feature for F14.**Since scilab*may be the best
> opensource*numerical computational software, is there someone interseted in
> packaging scilab for fedora?
>
> Regard,
> Chen Lei

Scilab is, in fact, in advanced packaging stage, waiting for JOGL.

--
Henrique "LonelySpooky" Junior
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 11:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org