December 2011 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] pom2spec
by Duncan Mac-Vicar P. 08 Dec '11

08 Dec '11

To revive the discussion about pom2spec :-) I was playing with it and it is exactly the kind of pragmatism one is missing when dealing with Java. Nice work Pascal. I remember there where a few topics open when Pascal presented it in the mailing list. - Naming while org.apache.maven.doxia.doxia-sink-api is already long, do you think it makes sense to prefix this with java- or jar- ? (like rubygems- do). I do think the whole groupId artifactId is the better way, but I am not sure if in all cases it would be needed. May be one could specify a shorter way (java-doxia-sink-api) in the command line, when ambiguity is not likely. Requires and Provides would still work using the Provides: java(org.apache.maven.doxia:doxia-sink-api) kind of string. - Provides. Right now it uses something like java(org.apache.maven.doxia:doxia-sink-api). I just want to point out that fedora is already using mvn(org.apache.maven.doxia:doxia-sink-api). Do we want to interoperate across them? Other points: - Binaries. For example: $ mkdir org.scala-tools.sbt.sbt-launch $ cd org.scala-tools.sbt.sbt-launch $ pom2spec call again and specify the exact version, one of: - 0.7.1 - 0.7.2 $ pom2spec 0.7.2 In this case, the built rpm misses the %{_bindir}/sbt which is just a call to java -Xmx512M -jar $longdir/sbt-launch.jar "$@" It would be a nice feature to tell pom2spec something like -bin sbt and it could create the script automatically. - One question... how is the classpath supposed to work? I see some .classpath files put together to the jars, but empty. - Why an artifact like Vaadin creates 2 rpms for the binary and 2 for the sources? Wrote: /space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-6.7.2-0.noarch.rpm Wrote: /space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-6_7_2-6.7.2-0.noarch.rpm Wrote: /space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-sources-6.7.2-0.noarch.rpm Wrote: /space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-6_7_2-sources-6.7.2-0.noarch.rpm -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 3

[opensuse-packaging] Another perl packaging question
by Greg Freemyer 07 Dec '11

07 Dec '11

All, I've been struggling to figure out a dependency issue with perl::IO::Compress. I have I think I finally understand it, but I want to ask before I branch perl itself and do a SR! In the D:L:P perl specfile it says: Provides: perl-Compress-Zlib perl-Compress-Raw-Zlib Obsoletes: perl-Compress-Zlib perl-Compress-Raw-Zlib Provides: perl-IO-Zlib perl-IO-Compress-Base perl-IO-Compress-Zlib Obsoletes: perl-IO-Zlib perl-IO-Compress-Base perl-IO-Compress-Zlib Note that all the component pieces of perl-IO-Compress are shown as provided, but the overall package itself is not in the list. That agrees with: http://perldoc.perl.org/index-modules-I.html. I have a package that has a requires perl(IO::Compress) and it is failing to install because of that. So my question is if the above list should have perl-IO-Compress added to it. Or should the requires statement in my package be changed to require all the component pieces of IO::Compress instead of just the overall package. To me updating the provides list seems right. Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 9

[opensuse-packaging] Packaging libraries that are intended to be static?
by David Lemke 07 Dec '11

07 Dec '11

I'm building a package that includes this library: http://www.lonesock.net/soil.html This library is "meant to be used as a static library", so, I'm wondering if I should package it separately or not? I read the following, but still feel uncertain about what to do: http://en.opensuse.org/openSUSE:Shared_library_packaging_policy Thanks! ~D -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4

[opensuse-packaging] Java OBS project key signing is expired
by Bruno Friedmann 07 Dec '11

07 Dec '11

Key: E38C29BC4276E0B9 Name: Java OBS Project <Java(a)build.opensuse.org> Finger Print: 9711921972E27C87BBC1BA89E38C29BC4276E0B9 Created: 01/22/08 Expires: 04/01/10 (The key is expired.) Please recreate it ps : for openjdk 1.7 there's no icewebtea -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2

[opensuse-packaging] Help with a perl module specfile
by Greg Freemyer 06 Dec '11

06 Dec '11

All, I have a package that is not building with the recent factory changes to not allow duplicate files: project=home:gregfreemyer:Tools-for-forensic-boot-cd package=perl-Image-ExifTool The error is: ERROR: /usr/share/man/man1/exiftool.1.gz is packaged in both exiftool and perl-Image-ExifTool, and the packages do not conflict I mean for it to be in the exiftool sub-package, but not in the main package perl-Image-ExifTool. Can someone tell me what I'm doing wrong? The relevant part of the specfile is: ======================== %prep %setup -q -n %{cpan_name}-%{version} %build %{__perl} Makefile.PL INSTALLDIRS=vendor %{__make} %{?_smp_mflags} %check %{__make} test %install %perl_make_install %perl_process_packlist %perl_gen_filelist # remove exiftool and exiftool.1.gz from the file list sed -i '/\/exiftool$/d;/\/exiftool.1$.gz$\?/d;' %{name}.files %clean %{__rm} -rf %{buildroot} %files -n exiftool %defattr(644,root,root,755) %attr(755, root, root) %{_bindir}/exiftool %doc %{_mandir}/man1/exiftool.1.gz %files -f %{name}.files %defattr(644,root,root,755) ExifTool.spec README xmp2exif.args xmp2gps.args xmp2iptc.args %doc Changes ExifTool_config README html %{perl_vendorlib}/File/RandomAccess.pm %{perl_vendorlib}/Image/ExifTool/* %doc %{_mandir}/man3/* ================================== Thanks Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrie… The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 5

[opensuse-packaging] Problem commiting a java -spec file
by Johannes Weberhofer 06 Dec '11

06 Dec '11

Inserting "Prefer: -java-1_6_0-sun java-1_6_0-openjdk" in a spec file results in the following error while commiting: error: line 23: Unknown tag: Prefer: -java-1_6_0-sun java-1_6_0-openjdk ERROR: source_validator failed: None Any ideas how to solve this issue? Best regards, Johannes -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] source service, correct revision from SVN
by Lutz Thuns 06 Dec '11

06 Dec '11

Hi, I'm packaging fatsort in my OBS project [1]. Therefore I'm using a source service which generates a .tar from SVN. <param name="versionprefix">0.9.15</param> sets me the correct main version, but regarding the revision, I receive a file called fatsort-0.9.15.rev247.tar.gz (notice the "rev"). If I don't use the versionprefix, the file is called fatsort-247.tar.gz Is there any possibility to ger rid of "rev", so that I receive a fatsort-0.9.15.247.tar.gz ? I've asked that on the English forums [2] a few weeks ago, maybe anybody here knows an answer. Thanks. [1] https://build.opensuse.org/package/show?package=fatsort&project=home%3AlOtz… [2] http://forums.opensuse.org/english/other-forums/development/open-build-serv… -- Lutz Thuns openSUSE member (lOtz1009) LXDE team -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

[opensuse-packaging] python-mongo and python-pymongo in devel:languages:python
by Adam Mizerski 05 Dec '11

05 Dec '11

Hi, There are two identical packages in devel:languages:python: python-mongo and python-pymongo. They have the same sources and a bit different spec files. According to http://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy the right one is python-pymongo. Please clean it up. Thanks. -- Adam Mizerski

1 0

[opensuse-packaging] %if 0%{?suse_version} >= 1210 not working?
by Lutz Thuns 05 Dec '11

05 Dec '11

Hi, I want to patch lxdm, to make it use the new location of the default OS wallpaper. Therefore I've added to the spec: > %if 0%{?suse_version} < 1210 > %patch0 -p1 > %endif [...other patches...] > %if 0%{?suse_version} >= 1210 > %patch6 -p1 > %endif This is working for Factory build target. For 12.1 build target it's not working. Patch0 is applied, but patch6 not. Also the original > %if 0%{?suse_version} >= 1210 > Recommends: gnome-control-center-user-faces > %endif is working for Factory only but not for 12.1 What am I doing wrong here? -- Lutz Thuns openSUSE member (lOtz1009) LXDE team -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] (In)Consistent Font Package Names
by Thomas Schraitle 04 Dec '11

04 Dec '11

Hi, over the years, I've collected a bunch of great fonts in my home repository. However, it seems we don't have a consistent naming schema for fonts. Although the Packaging Guidelines[1] links to the old Wiki[2], the information therein is printed in red and I'm not sure how useful is this nowadays. This has some interesting effects. If you search for fonts like this: # zypper se font you will get _some_ but not all. For example, the popular Linux Libertine and DejaVu fonts are not listed. A user has to _know_ the name. IMHO this is not very intuitive and userfriendly. On the other side, we have lots of fonts which are very inconsistently named. Here are some examples: farsifonts fonts-arabic freefont gnu-unifont indic-fonts intlfonts-ttf xorg-x11-fonts From a usability perspective, it would be very convenient to have a consistent naming schema with a specific prefix (or suffix), for example a "-fonts" suffix. Ubuntu has the prefix "ttf-" for their packages: http://packages.ubuntu.com/search?suite=natty&section=all&arch=any&searchon… Fedora has the suffix "-fonts" for their packages: https://admin.fedoraproject.org/pkgdb/acls/list/*-fonts*?_csrf_token=b27215… Another issue: Do we have a special repository dedicated only to fonts? I couldn't find any... Do you think this is useful? What do you think? -------- [1] http://en.opensuse.org/openSUSE:Packaging_guidelines [2] http://old-en.opensuse.org/Packaging/Fonts_Policy#Package_layout_for_fonts -- Gruß/Regards, Thomas Schraitle ---------------------------------------------------------------------- SUSE LINUX Products GmbH (o< Maxfeldstrasse 5 /\\ Documentation Specialist 90409 Nuernberg, Germany _\_v http://www.suse.com http://lizards.opensuse.org/author/thomas-schraitle/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

11 19