September 2012 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Adding openSUSE 12.2 repository for devel:languages:pascal
by Kirill Kirillov 15 Sep '12

15 Sep '12

Hello, all Could you please add openSUSE 12.2 repository in openSUSE Build Service - devel:languages:pascal project. It is needed by 'hedgewars' game, which aggregates 'fpc' package from this repository, so for now this game cannot be built for oS 12.2 due to this fact. Thanks. -- Kirill Kirillov <>< -- 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] Conflicting C and C++ declarations?
by Ilya Chernykh 15 Sep '12

15 Sep '12

What should I do? [ 49s] ./main.h:38:15: error: previous declaration of 'char** environ' with 'C++' linkage [ 49s] In file included from util.cpp:45:0: [ 49s] /usr/include/unistd.h:546:15: error: conflicts with new declaration with 'C' linkage https://build.opensuse.org/package/rawlog?arch=x86_64&package=xxdiff&projec… -- 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] Sub packaging or extra
by Togan Muftuoglu 15 Sep '12

15 Sep '12

Hi, It is a general question actually, but what is the recommended approach when one is packaging more then one source package? I have a main package with its' source file and then small source packages that would enhance the main package and some of them have different licenses in relation to the main source. These small packages do need the main package as otherwise they are useless. Currently I am inclined to create sub packages so when eventually the package goes in to Factory, I don't have to submit X number of packages but only one ;). However, experience has taught me as well when the package is maintained for different releases then there are lots of if/else/endif blocks going on and with these sub-packages it means more work to keep them building and functioning as the spec file itself becomes big. On the other hand if I create separate packages that would mean I need to submit each one separately and still need to maintain for the different releases. It probably is a taste issue, but would like to hear others' thoughts as well Thanks Togan -- 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] vdr, lirc, dvb looking for new maintainer
by Ludwig Nussel 14 Sep '12

14 Sep '12

Hi, Due to lack of hardware I no longer actually use lirc nor vdr so I shouldn't be maintaining the packages anymore either. I hardly invested any time in those packages the last years but still had no complaints. So either noone uses them either or the software is just perfect :-) Anyone willing to take over maintainership? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (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

4 11

[opensuse-packaging] Why this package fails without even starting build?
by Ilya Chernykh 13 Sep '12

13 Sep '12

https://build.opensuse.org/package/show?package=xxdiff&project=home%3AAnsus… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 3

[opensuse-packaging] plan for 12.3 - multiple Python runtimes
by Jan Matejek 13 Sep '12

13 Sep '12

fellow openSUSErs, with the advent of Python 3 and still almost unnoticeable decline of Python 2, i have come to a realization that the way we separate them into "python" and "python3" is less than ideal. The granularity of this can be often too coarse (you can't run two apps requiring two different python2 versions, unless they are specifically packaged and bring their own python runtime package), and too fine at the same time (there are already packages that don't actually care whether they run in python 2 or 3) In the spirit of fixing what ain't broken, I humbly propose a grand plan: let's turn "python" into "python2.7", "python3" into "python3.3", and tinker with Provides until it all works just fine. Then, as a last step, symlink /usr/bin/python into /etc/alternatives and let the users pick whichever runtime they like better. This would probably go better if broken into several phases. My current idea is this: Phase 1: - rename "python" to "python2.7", providing "python = 2.7" - rename "python3" to "python3.3", providing "python3 = 3.3" - install the update-alternatives symlink Impact: - Unsure of what would happen on package upgrade. Would we need Obsoletes/Provides combo for this? Perhaps we'd have to create the metapackages outlined in the following phases at this point already. Phase 2: - unify RPM macros - python3 will have %py_(something) macros as well as %py3_(something) macros, the %py3_ versions being aliases to the %py_ versions - make python2.7 provide "python2 = 2.7" instead of "python = 2.7" - make a "python" meta-package requiring, at this time, python2 - each pythonX.Y package now only installs /usr/bin/pythonX.Y binary, python2 and python3 are alternatives for python2.Y and python3.Y respectively, and python is an alternative for either python2, python3, or a specific version. I don't know update-alternatives too well - is this even viable? Impact: - this should mark a clear upgrade path for each of the python variants and for the systemwide "default python" as well - at this phase, i would like to make it possible to build a package for any python (2 or 3 or 50) from the same specfile. i'm not sure that these outlined steps are enough, though. Originally I thought that every python would provide "python = X.Y" and the packages could select which "Requires: python" to pick through package or project meta. But that would result in a horrible breakage, and we need "python" as a separate package for upgrading in any case. We could use "python(abi)" symbol for this, or do the same just with "python-devel"? Any other options? Phase 3A: - when python 3.4 comes out, introduce a new package "python3.4", new meta-package "python3" requiring "python3.4", and corresponding alternatives Impact: - This is the other difficult one. What about lifetime of the pythonX.Y packages? What happens with old systems on perpetual-upgrade? Such as tumbleweed - will the old python runtimes rot there forever-and-ever, or can we force uninstall at some point? Perhaps "Obsoletes: python3 < 3.x" in the "python3" metapackage? Which versions do we support? The newest and the most popular, probably? I know we do something similar with gcc, how does it work there? Phase 3B: - steal and improve Debian's python-central (or however they call it these days) - designate /usr/lib/python-central or something similar for packages that don't want to depend on a specific python runtime version - introduce %post/%postun scriptlet macros for packages that would compile bytecode in /usr/lib/python-central for all known python runtimes on the system, and for pythons so that they compile every package for their versions. This is now actually fully supported by upstream, we can have as many different versions of bytecode for the -same- .py file as we want. Impact: - package can specify "Requires: python" and Just Work(tm) from now until eternity, or until it runs into a deprecated API. Or specify a range of pythons it wants to support - by the time we get here, I'm sure RPM will allow that ;e) With a limited ABI in python3, this can even work for arch-based packages across python minor versions. Phase 4: - when we decide to switch to python3 system-wide, make "python" require "python3" instead of "python2", change default alternative, and be done with it Impact: - breakage of packages still incompatible at that time. that will help us see what needs fixing and what needs to explicitly specify that it wants python2. Somewhere in this is lurking a possibility of supporting different python runtimes such as Jython, Cython, PyPy and whatever else crops up. That's neat, too. Thanks for your attention. Comments, questions? regards m. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 11

[opensuse-packaging] So I packaged up darcs; now what do I do with it?
by Damien Radtke 13 Sep '12

13 Sep '12

Darcs is a version control system written in Haskell, and in order to learn more about packaging, I decided to try and package it up. As luck would have it, I now have a fully packaged version sitting in my home repository: https://build.opensuse.org/package/show?package=darcs&project=home%3Akog13 It has build dependencies on packages in devel:languages:haskell and devel:languages:haskell:next, but the program itself can be used for more than Haskell development. So my question comes in several parts: 1) Where would the ideal place to submit this package be? Is it too late to get it in one of the default repos for 12.2, or would Packman be better? 2) Am I correct in thinking that the repos holding build dependencies (in this case, the haskell development repos) aren't necessary to be subscribed to when a user installs it? 3) What are some things to keep in mind when trying to submit new packages to a repository? I'm pretty new at this, so any help or advice is welcome. Thanks, ~Damien -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 7

[opensuse-packaging] Where do screenshots come from?
by Greg Freemyer 12 Sep '12

12 Sep '12

All, I recently packaged httrack and I see on http://software.opensuse.org/search?q=httrack there is a screenshot. I'm just curious where that came from. Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3

[opensuse-packaging] SLE11 and libgomp
by Claudio Freire 11 Sep '12

11 Sep '12

Hi. Another issue with SLE11 I cannot find information about. I have a package that requires libgomp, but a specific version of it. All other opensuse versions work by BuildRequiring "libgomp.so.1(GOMP_2.0)". But SLE11 doesn't seem to get the hint. Thing is, the build log[0] says libgomp46 is being installed, which ought to be right (libgomp45 works). But somehow, it isn't. I could find the gcc packages in OBS for openSUSE, to try to see what may be wrong with the BuildRequires, and in fact that's how I came up with that buildreq. But not for SLE. Any idea guys? [0] https://build.opensuse.org/package/live_build_log?arch=x86_64&package=octav… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 5

[opensuse-packaging] Packaging Guidelines documentation in need of TLC
by Togan Muftuoglu 11 Sep '12

11 Sep '12

Hi, I was going to update couple of lua packages but I could not found any relevant information of lua packaging in <http://en.opensuse.org/openSUSE:Packaging_guidelines>. Now Fedora has a draft documentation at <http://fedoraproject.org/wiki/PackagingDrafts/Lua> and Debian has <http://pkg-lua.alioth.debian.org/policy.html> But the problem is not limited lua only, as currently openSUSE has no packaging policy for Lisp, Haskel, R. So looks like the documentation is neeeding TLC (Tender Love Care) if the goal is to have a higher packaging quality (ie. well documented patches and etc) Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0