Suggested updated Java guidelines
by Alexander Boström
Hi,
I submitted a review for java-gnome and working on that made me think
the Java guidelines needs work, so here's a suggested update:
https://fedoraproject.org/wiki/User:Abo/JavaPackagingDraftUpdate
=== Changes ===
Removed some occurances of a Unicode control character that didn't seem
to belong there.
Fixed formatting of the text under "Jar file naming".
Hopefully clarified the text under "Directory structure".
Changed some occuranced of "<code>%{_xxx</code>}" into
"<code>%{_xxx}</code>".
Changed -javadoc Group tag from "Development Documentation" to
"Documentation".
Mostly rewrote the section on JNI packaging. (See wiki.)
Removed this text:
The <code>%{_jnidir</code>} rpm macro defines the main JNI jar
repository. Like <code>%{_javadir</code>} it is declined in
<code>-ext</code> and <code>-x.y.z</code> variants. It follows
exactly the same rules as the <code>%{_javadir</code>}-derived
tree structure, except that it hosts JAR files that use JNI.
<code>%{_jnidir</code>} usually expands into
<code>/usr/lib/java</code>.
It seems to belong to the "The plan is to eventually..." part, but I
don't really understand it. Explain and I'll add something back. :)
Partially rewrote the section on prebuilt binaries and the suggested %
prep section. (See wiki.)
/abo
13 years, 8 months
Impasse on packaging JOGL and Gluegen
by Henrique Junior
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
http://br.maisbuscados.yahoo.com
13 years, 9 months
Help packaging Jogl/Gluegen
by Henrique Junior
Hi, to make Scilab[1] available in Fedora we need to package JOGL/Gluegen[2] first.
Sylvestre
Ledru (Debian's maintainer) and I started to work on the packaging, but
as he is not familiar with the structure used in Fedora and as I have
no experience with Java, we've reached the point of needing some help.
Anyone here installed JOGL before and is familiar with your settings?
Here are a few installation steps:
-----------------------------------------
Hi, Sylvestre,
To understand how to
install jogl and gluegen I'm trying a simple install first. Both,
jogl and gluegen are placed side by side:
[lonely@localhost
jogl]$ pwd
/home/lonely/jogl
[lonely@localhost
jogl]$ ls
gluegen jogl
CLASSPATH is unseted:
[lonely@localhost
jogl]$ echo $CLASSPATH
And
make/gluegen.propertiess is in my home. Using "locate" I can see 3 antlr.jar in my system:
l[root@localhost ~]# locate antlr.jar
/usr/share/ant/lib/ant-antlr.jar
/usr/share/java/antlr.jar
/usr/share/java/ant/ant-antlr.jar
I'll be pointing gluegen.propertiess to /usr/share/java/antlr.jar and commenting this win32.c.compiler=vc6
jogl.properties is in my home also, but I'm not sure where to point it. I have OpenJDK installed (including the devel package):
[root@localhost ~]# locate *openjdk
/etc/alternatives/java_sdk_openjdk
/etc/alternatives/jre_openjdk
/usr/lib/jvm/java-1.6.0-openjdk
/usr/lib/jvm/java-openjdk
/usr/lib/jvm/jre-1.6.0-openjdk
/usr/lib/jvm/jre-openjdk
/usr/lib/jvm-exports/java-1.6.0-openjdk
/usr/lib/jvm-exports/java-openjdk
/usr/lib/jvm-exports/jre-1.6.0-openjdk
/usr/lib/jvm-exports/jre-openjdk
/usr/lib/jvm-private/java-1.6.0-openjdk
/var/lib/alternatives/java_sdk_openjdk
/var/lib/alternatives/jre_openjdk
When I run ant in "/make" I got this:
BUILD FAILED
/home/lonely/jogl/jogl/make/build.xml:1562: The following error occurred while executing this line:
/home/lonely/jogl/jogl/make/build.xml:487: The following error occurred while executing this line:
/home/lonely/jogl/gluegen/make/build.xml:458: The following error occurred while executing this line:
/home/lonely/jogl/gluegen/make/build.xml:378: The following error occurred while executing this line:
/home/lonely/jogl/gluegen/make/gluegen-cpptasks.xml:400: suncc is not a legal value for this attribute
If you want to take a look at the compilation log, look at the attachment.
Please, take in mind that I'm a java n00b ;)
[1] - http://www.scilab.org/
[2] - https://bugzilla.redhat.com/show_bug.cgi?id=439630
SOURCE: http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.1a/jogl-1....
BUILD INSTRUCTIONS: http://download.java.net/media/jogl/doc/HowToBuild.html
------------------------------
Henrique "LonelySpooky" Junior
____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
13 years, 9 months
fc13 RPM dep generator issue
by Michael Schwendt
https://bugzilla.redhat.com/566419
An fc13 build of "muse" is missing automatic SONAME deps.
The fc12 and fc11 builds made on the same day are fine.
The "muse" packages disables the internal dep generator to filter
the Provides. Somehow this disables also the Requires.
Has anything in fc13 RPM changed that would also affect packages
other than this?
13 years, 9 months
Next FPC Meeting
by Toshio Kuratomi
Greetings all, it's time for another of our bi-weekly meetings. Same time
since we still haven't figured out a time that works better for everyone::
Wednesday at 16:00 UTC, in #fedora-meeting
I may not be able to attend this meeting as I think I'll be traveling to the
airport during that time but spot will be present to run the meeting. These
are the things on the agenda for this week and my votes (unless I can make
it):
Complex Font Template fix --
https://fedoraproject.org/wiki/Fix_Complex_Font_Template(draft)
This is also something that FESCo asked us to look at. Since the Complex
Fonts template results in unexpanded macros showing up in SRPMs, we need to
look at correcting the template to comply with the Buildtime Macro . There were two suggestions on the mailing
list. I've put them both there. No answer from the fonts sig about which
they'd prefer so it's just a matter of choosing one.
|-
RPMMacros improvements --
https://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_o...
Till made a bunch of small cleanups for this page.
I'm +1
|-
Which files to include in python modules --
http://fedoraproject.org/wiki/Packaging/No_py_removal%28draft%29
Ville drafted a proposal in response to the question of whether we should
remove *.py files in Fedora. Here's the addition to the python Guidelines
for that.
I'm +1
|-
Static Library PICness --
http://fedoraproject.org/wiki/User:Ajax/Static_Library_PICness_Guidelines
Ajax drafted this guideline as a response to seeing Debian asking for
an explicit okay to package PIC compiled code in static libraries.
I'm okay with the concept but I've left comments on the page for things I'd
like to see clarified so reviewers know what to look for and packagers know
how to deal with the issue.
I'm +0 until more work is done on addressing the comments. I can vote on
the list if something new gets drafted.
|-
CMPI Plugin Guideline --
http://fedoraproject.org/wiki/PackagingDrafts/CMPIPlugins
mdomsch wrote this for CMPI Plugins. There's a few outstanding questions on
the page that need to be addressed. We can look it over for other things we
want addressed but I don't think this is ready for a vote yet.
If it comes up for a vote, I'm +0 until the questions are resolved. I can
vote on the list if something new gets drafted.
|-
Clarify line between bundled libraries and copied snippets of code --
https://fedorahosted.org/fesco/ticket/314
This is the big issue this week. It's something that FESCo has asked us to
look into. There's a bit of homework involved as we need to take a look at
the code in the first set listed there and see if:
1) We'd recommend an exception for any of them
2) Would we put any conditions on the bundling (like upstream needs to get
this code into a state to unbundle), you must contact upstream, you must
work on a patch, etc.
3) Can we draw any general criteria out of it so that we don't have to push
as many things through the exception process (or if they do, there are some
pretty clear rules of whether something should be granted an exception or
not.)
These are the three files to examine:
* http://core.trac.wordpress.org/browser/branches/2.8/wp-includes/canonical...
* http://core.trac.wordpress.org/browser/branches/2.8/wp-includes/wp-db.php
* http://core.trac.wordpress.org/browser/branches/2.8/wp-includes/Text/Diff...
If people do look at the source code and the history of the libraries that
are being bundled before the meeting, I think we could make a recommendation
on those specific three files. Looking for general criteria is probably
something that we can throw ideas out at the meeting, discuss them on the
list, and then generate some useful discussion for a formal draft.
-Toshio
13 years, 9 months
remove source files
by Scott Frankel
Hi all,
What's the best way to remove source files during a package build?
I'm quite new to rpm packaging.
I'm using a simple spec file to package a python-based application for
distribution. When passed to rpmbuild, it creates an rpm with both
source (.py) and bytecode compiled (.pyc) files. I'd like to remove
the source files from the rpm.
Thanks in advance!
Scott
13 years, 9 months
Complex Fonts Template Change
by Toshio Kuratomi
At FESCo's behest, I've drafted a change to the complex font templates so
that they don't conflict with the macros must be expanded in the SRPM
%description and summary:
https://fedoraproject.org/wiki/Fix_Complex_Font_Template(draft)
This will get discussed at the next meeting but I'd love to see two pieces
of input from the fonts SIG before that occurs.
1) Of the two methods, (I know both are disliked) which is the preferred
method to the fonts SIG? Is there another method that would be preferable
that does not leave an unexpanded macro in the SRPM %description?
2) If you want to make your case that the SRPM is of lesser importance than
binary rpms so unexpanded macros that don't contain information that would
be useful in the description anyway are allowed, please add it as another
option for FPC to consider.
-Toshio
13 years, 9 months
Update on packages violating the Static Library guidelines
by Michael Schwendt
* Early-warning system => "binutils" was closed WONTFIX:
https://bugzilla.redhat.com/556040
I may need some backup in case the reopened ticket will be ignored.
* Bugzilla status for packages violating the Static Library guidelines:
http://mschwendt.fedorapeople.org/staticbugstat.html
acl 556036 -> CLOSED
atlas 556037 -> CLOSED
attr 556038 -> CLOSED
audit 556039 -> CLOSED
binutils 556040
brltty 556041
Canna 556034 -> CLOSED
cdparanoia 547682 -> CLOSED
comedilib 556043
dnssec-tools 556044
e2fsprogs 545144
expat 556046 -> CLOSED
fftw2 556047
file 556048 -> CLOSED
gcc 556049
gdbm 556050
ghostscript 556051 -> CLOSED
gnutls 556052 -> CLOSED
gpsim 556053
gtk+extra 556054 -> CLOSED
hpic 556055 -> CLOSED
isdn4k-utils 556056
js 556057 -> CLOSED
ldns 556058 -> CLOSED
libaio 556059 -> CLOSED
libannodex 556060 -> CLOSED
libbtctl 556061
libcaca 556062
libcddb 556063 -> CLOSED
libcdio 556064 -> CLOSED
libcmml 556065
libdnet 556066
libevent 556067
libftdi 556068 -> CLOSED
libnl 556069
liboggz 556070 -> CLOSED
libotr 556071
librx 556072 -> CLOSED
libsemanage 556073 -> CLOSED
libsndfile 556074
libstatgrab 556075
libtranslate 556076
libtwin 556077
libuninameslist 556078 -> CLOSED
libxslt 556079
link-grammar 556080
linux-atm 556081
linuxwacom 556082 -> CLOSED
lockdev 556083 -> CLOSED
meanwhile 556084 -> CLOSED
mpich2 545149 -> CLOSED
munipack 556086
nfs-utils-lib 556087
numactl 556088
opencdk 556089
openldap 556090 -> CLOSED
proj 556091
python 556092 -> CLOSED
QuantLib 556035 -> CLOSED
rubberband 556093
shapelib 556094 -> CLOSED
syck 556095
sysfsutils 556096 -> CLOSED
texlive 556097 -> CLOSED
torque 556098
util-vserver 556099
xbsql 556100 -> CLOSED
xen 556101
xfsprogs 556102
xmlsec1 556103
xqilla 562566
13 years, 9 months
RPM for CPAN module - Issues with Provides:
by Pedro Padron
Hi there,
I'm creating a specfile for a CPAN module and I'm facing some issues
with the Provides: tag.
The module I want to package (Nmap::Scanner) creates Perl namespaces
on-the-fly using Class::Generate, so the perl.prov script can't detect
them. This of course creates an incomplete list of Provides:, which
conflicts with the list of Requires:. Therefore the RPM package cannot
find the dependencies provided by itself.
I would like to know what would be the recommended alternative for
adding the missing Provides:.
In Bug #167797 [1] there was the alternative of patching the code and
submitting the patch upstream. In this case it would be unreasonable,
since the module would have to be basically rewritten.
Should I just add a bunch of Provides: in the spec header like this?
Provides: perl(Nmap::Scanner::Address)
Provides: perl(Nmap::Scanner::Distance)
Provides: perl(Nmap::Scanner::ExtraPorts)
Provides: perl(Nmap::Scanner::Host)
Provides: perl(Nmap::Scanner::Hostname)
Provides: perl(Nmap::Scanner::Hosts)
Provides: perl(Nmap::Scanner::NmapRun)
Provides: perl(Nmap::Scanner::OS)
Provides: perl(Nmap::Scanner::OS::Class)
Provides: perl(Nmap::Scanner::OS::Fingerprint)
Provides: perl(Nmap::Scanner::OS::IPIdSequence)
Provides: perl(Nmap::Scanner::OS::Match)
Provides: perl(Nmap::Scanner::OS::PortUsed)
Provides: perl(Nmap::Scanner::OS::TCPSequence)
Provides: perl(Nmap::Scanner::OS::TCPTSSequence)
Provides: perl(Nmap::Scanner::OS::Uptime)
Provides: perl(Nmap::Scanner::Port)
Provides: perl(Nmap::Scanner::RunStats)
Provides: perl(Nmap::Scanner::RunStats::Finished)
Provides: perl(Nmap::Scanner::ScanInfo)
Provides: perl(Nmap::Scanner::Service)
Provides: perl(Nmap::Scanner::Task)
Provides: perl(Nmap::Scanner::TaskProgress)
[1] https://bugzilla.redhat.com/show_bug.cgi?id=167797
Thanks,
Pedro Padron
ppadron(a)w3p.com.br
13 years, 9 months
