packaging February 2010

packaging@lists.fedoraproject.org

27 participants
17 discussions

Mention %{_sharedstatedir} difference on RPMMacros for EPEL
by Till Maas 31 Mar '10

31 Mar '10

Hiyas, I noticed that the RPMMacros page does not mention that %{_sharestatedir} expands to %{_prefix}/com on CentOS and probably also RHEL: https://fedoraproject.org/wiki/Packaging:RPMMacros Also it would be nice to have the notes about differences in other releases inside a admonition, to make them easier visible. Regards Till

8 15

Suggested updated Java guidelines
by Alexander Boström 16 Mar '10

16 Mar '10

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

3 3

Impasse on packaging JOGL and Gluegen
by Henrique Junior 01 Mar '10

01 Mar '10

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

2 3

Help packaging Jogl/Gluegen
by Henrique Junior 28 Feb '10

28 Feb '10

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.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

4 6

fc13 RPM dep generator issue
by Michael Schwendt 18 Feb '10

18 Feb '10

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?

2 2

Next FPC Meeting
by Toshio Kuratomi 17 Feb '10

17 Feb '10

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_opt… 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.p… * 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.p… 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

3 2

remove source files
by Scott Frankel 16 Feb '10

16 Feb '10

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

7 16

Complex Fonts Template Change
by Toshio Kuratomi 13 Feb '10

13 Feb '10

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

1 0

Update on packages violating the Static Library guidelines
by Michael Schwendt 11 Feb '10

11 Feb '10

* 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

6 8

RPM for CPAN module - Issues with Provides:
by Pedro Padron 10 Feb '10

10 Feb '10

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

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging February 2010