April 2011 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Re: commit jpeg8 for openSUSE:Factory
by Dimstar / Dominique Leuenberger 15 Apr '11

15 Apr '11

Hello community, Just saw this commit on the ml and thought I wanted to raise an issue/question with this one (there are others doing the same) It's also not this commit introducing it, just that I happen to see it here... again... and I have time now :) > -%package -n libjpeg8-devel > +%package -n libjpeg%{major}-devel Wasn't there once the agreement that the -devel package does not follow the sonum bumps? so sonum in the packagename for libs is only interesting because it allows us to install the libs in parallel, something which the -devel package here intentionally 'denies' us from doing using Conflicts: anyhow. Why not just go and call it libjpeg-devel, which would also be more straight forward for packagers, relying on it. I think it's useless to update all spec files just becuase jpeg (or any other lib for that matter) bumps it soname and becomes ABI incompatible.. as long as they are API compat, a rebuild is all it takes. Habing '8' in this case in the packagename for the devel will force us to go and replace all BuildRequires: libjpeg8-devel with libjpeg9-devel. This is actually also noted down like this in our packaging guidelines, see: http://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Package_Name Best regards, Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

8 14

[opensuse-packaging] On Python packages naming
by Sascha Peilicke 15 Apr '11

15 Apr '11

Hi guys, currently most Python packages in the Build Service are inconsistently named. For instance, upstream 'pyenchant' is named python-enchant, 'Cheetah' is named python-cheetah. There are plenty of other examples. I'd like to propose a different scheme (much like our Ruby and Perl packages): * Python application packages are named like $UPSTREAM_NAME * Python libraries are named python-$UPSTREAM_NAME Upstream names means what is found on PyPi (pypi.python.org) PyPi names make the most sense as upstream projects names clash sometimes, PyPI names are unique. Here are some examples: * 'bpython' stay 'bpython' as it is an app * 'IPython' would become 'ipython', as this is the PyPi package name (not the app name) * 'python-enchant' becomes 'python-pyenchant' * 'python-cheetah' becomes 'python-Cheetah' * 'python-twitter' becomes 'python-python-twitter' While the last example doesn't look too fancy, this generally has huge advantages. First of all users now have a clue what to search for. More importantly, there's a clear dependency between package name and upstream name, which helps a lot for automatic spec file generation (BuildRequires/Requires). For some newer packages, this seem to have happened already. I'd suggest that when a new upstream version for a 'broken' package is available, an entirely new package (with correct name) is added and the old one obsoleted. Python applications should also Provide: python-$UPSTREAM_NAME to be compatible with the above scheme. As an example, I added the package 'python-pyenchant' to devel:languages:python, that obsoletes/provides the older 'python-enchant'. -------------------------------------------------------------------------------- Regarding BuildRequires/Requires, we may even want to adopt the Perl package scheme. For the package 'python-py2pack' this would look like: BuildRequires: python-devel BuildRequires: python(Jinja2) >= 2.5 BuildRequires: python(argparse) Requires: python(Jinja2) >= 2.5 Requires: python(argparse) This needs some tool support, off course. -- Mit freundlichen Grüßen, Sascha Peilicke http://saschpe.wordpress.com

5 8

Fwd: [opensuse-packaging] Re: On Python packages naming
by Nelson Marques 15 Apr '11

15 Apr '11

---------- Forwarded message ---------- From: Nelson Marques <nmo.marques(a)gmail.com> Date: Fri, Apr 15, 2011 at 7:49 PM Subject: Re: [opensuse-packaging] Re: On Python packages naming To: Jan Matejek <jan.matejek(a)novell.com> Hi, As far as I understood and it was pointed to me, python extensions, modules, bindings and friends are to be packaged as python-$whatever, while user applications are not to follow that and to be packaged by their name. I would love to see a more friendlier solution, but I don't find the current way also too complex... as long as the packager knows what he is packaging it should be cake... Yeah, I know the nasty RPMLINT warning, but that can either be worked with rpmlint or it really doesn't hurt to be ignored. Most people will be aware of it's meaning and will why it's there (a user application). It will be far more complicated to identify python modules/extensions following other ways... By the way, I might be wrong, but isn't PyEnchant already a part of python or python-xml ? NM On Fri, Apr 15, 2011 at 7:27 PM, Jan Matejek <jan.matejek(a)novell.com> wrote: > Dne 15.4.2011 17:02, Sascha Peilicke napsal(a): >> >> On Friday 15 April 2011 16:13:49 İsmail Dönmez wrote: >>> >>> On Friday, April 15, 2011 04:13:00 PM Andreas Jaeger wrote: >>>> >>>> On Friday, April 15, 2011 03:46:34 PM Sascha Peilicke wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> currently most Python packages in the Build Service are inconsistently >>>>> named. For instance, upstream 'pyenchant' is named python-enchant, >>>>> 'Cheetah' is named python-cheetah. There are plenty of other examples. >>>>> I'd like to propose a different scheme (much like our Ruby and Perl >>>>> packages): >>>>> >>>>> * Python application packages are named like $UPSTREAM_NAME >>>>> * Python libraries are named python-$UPSTREAM_NAME >>>> >>>> Sascha, what are other projects like Debian, Ubuntu and Fedora doing? >>>> Let's talk with other rpm based distros on whether we can implement the >>>> same scheme - this make cross-distribution building much saner... >>> >>> This is a good idea, python-python-twitter looks really counter-intuitive >>> though, maybe there should be an exception if the package already has a >>> python- prefix. >> >> Yeah, if it's 'python-' we may want to drop that prefix. This seems to be >> the >> case for our Perl and Ruby packages, too. > > +1 to this > -- > To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org > For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org > > -- Nelson Marques /* As cicatrizes lembram-nos de onde estivemos, mas não ditam para onde vamos */ -- Nelson Marques /* As cicatrizes lembram-nos de onde estivemos, mas não ditam para onde vamos */ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] multimedia:apps coriander links to DISCONTINUED:openSUSE:11.1 coriander
by Dave Plater 14 Apr '11

14 Apr '11

I just had a submit request to multimedia:apps coriander which had a broken link to "DISCONTINUED:openSUSE:11.1 coriander", the submitters package was also linked to "DISCONTINUED:openSUSE:11.1 coriander". I deleted mmaps coriander and used osc copypac from the submitters home project to recreate mmapps coriander and because it was there before, recreated the mmapps link. Can somebody enlighten me as to why coriander is linked to DISCONTINUED:openSUSE:11.1? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 4

[opensuse-packaging] File locations question
by Togan Muftuoglu 13 Apr '11

13 Apr '11

Hi, I am maintainting shorewall packages in security:netfilter and with the recent shorewall package locations of some files have gained flexibility Quoting from the release notes "Distributions have different philosophies about the proper file hierarchy. Two issures are particularly contentious: - Executable files in /usr/share/shorewall*. These include; getparams compiler.pl wait4ifup shorecap ifupdown - Perl Modules in /usr/share/shorewall/Shorewall. To allow distributions to designate alternate locations for these files, the installers (install.sh) now support the following environmental variables: LIBEXEC -- determines where in /usr getparams, compiler.pl, wait4ifup, shorecap and ifupdown are installed. Shorewall and Shorewall6 must be installed with the same value of LIBEXEC. The listed executables are installed in /usr/${LIBEXEC}/shorewall*. The default value of LIBEXEC is 'share'. LIBEXEC is recognized by all installers and uninstallers. PERLLIB -- determines where in /usr the Shorewall perl modules are installed. Shorewall and Shorewall6 must be installed with the same value of PERLLIB. The modules are installed in /usr/${PERLLIB}/Shorewall. The default value of PERLLIB is 'share/shorewall'. PERLLIB is only recognized by the Shorewall and Shorewall6 installers and the same value must be passed to both installers. " Now in terms of the LIBEXEC, I am planning to place them under /usr/lib/shorewall. However I a not sure what to do with the perl modules so I need help in defining what ${PERLLIB} should be. Thanks Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 2

[opensuse-packaging] gettext.so: undefined symbol: Perl_pad_sv
by Robert Xu 11 Apr '11

11 Apr '11

Hi all, For some reason, any package that is using gettext (or perl-Gettext, still trying to figure out which) is failing with the following error: gettext.so: undefined symbol: Perl_pad_sv These two bugs probably have something to do with it. http://bugs.gentoo.org/show_bug.cgi?id=343405 https://bugzilla.redhat.com/show_bug.cgi?id=518896 Anyone else getting encumbered by this problem? I am building off the latest openSUSE:Factory on a local instance of OBS. -- Robert Xu + Linux is awesome; don't doubt what it can do + rxu(a)lincomlinux.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 2

[opensuse-packaging] rpmlint - non-utf8-spec-file ?
by Per Jessen 08 Apr '11

08 Apr '11

What does this mean: RPMLINT report: =============== jfsutils.src: W: non-utf8-spec-file /tmp/rpmlint.jfsutils-1.1.15-1.src.rpm.zuUJ47/jfsutils.spec The character encoding of the spec file is not UTF-8. Convert it for example using iconv(1). The spec file contains only US-ASCII, I've checked. What does rpmlint know that I don't? -- Per Jessen, Zürich (14.6°C) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 6

[opensuse-packaging] blog post series started for rpmlint and brp warnings / errors
by Dominique Leuenberger a.k.a DimStar 08 Apr '11

08 Apr '11

Hi everybody, We know them all and some of us get frustrated by them: lints and brp checks aborting our builds, even though make and make install perfectly passed through (well, one correction here already: APPARENTLY perfectly passed). I do not argue against the checks at all and I think they are a good thing (tm). But sometimes they can be a little bit cryptic and most of the time require work. so I started a series of blog posts (2 so far) which try to address them. Please bare with me, I'm no hard core crack coder, but I will try to summarize the usual causes and solutions to a problem. Not in every case will the provided solution fit and if you're not sure about correctness in your package: discuss the matter with upstream. Anyway, once you produce a patch, you should always make sure upstream gets it too. So what were the blog posts about so far? Part 1: how to fix brp and rpmlint warnings ? today: Expression compares a char* pointer with a string literal http://dominique.leuenberger.net/blog/?p=151 Part 2: how to fix brp and rpmlint warnings ? today: I: Program causes undefined operation (likely same variable used twice and post/pre incremented in the same expression) http://dominique.leuenberger.net/blog/?p=178 As noted on the first entry, i will gladly take recommendations for which errors you would like to see an entry. I will try to write them up, likely 1 or 2 per week (I am actually not that much of a writer... 0 Hope the series is useful to you... If it saves you a few minutes here and there, then it is. Best regards, Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 5

[opensuse-packaging] data has a longer lifetime than libraries that read the data;What package should own the data directory?
by Paul Elliott 07 Apr '11

07 Apr '11

I have also asked this question on debian-mentors; I thought I would get an opensuse perspective as well. I am working on packaging the Swiss Ephemeris. The Swiss Ephemeris uses a single directory to hold all its data. (Settable by the programmer, so a private directory can be used.) Call this directory the slush fund of data. I want to encourage different programs to share data in one big installed directory, so that different astrology programs do not all have their own private copies of this data. Which is the same. And a large user of space. The upstream has assured me that this data will always be downward compatable, so that if new data formats are ever introduced that old versions of the libraries can not read, new file names will be used for that data, so that old libraries will never try to open files that they can not understand. Any particular data file could be needed or not needed, installed or not installed depending on what is being done. Except for a few short files that should always be there, but they might need to be upgraded with new versions. My problem is: "What package should own the slush fund?" It should not be the library, because when the library upgrades most of the data does not become invalid. Would not want to delete and reinstall all the data at this point. Should not be the package for any particular file, because that package may not be needed hence not installed. Must I create one special essentially imortal package to own the "slush fund"? -- Paul Elliott 1(512)837-1096 pelliott(a)BlackPatchPanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117

1 0

[opensuse-packaging] distro independant rpms and debs for distro independant data?
by Paul Elliott 07 Apr '11

07 Apr '11

This question concerns both the OBS and packaging so I am sending to both lists. I am currently working on packaging the Swiss Ephemeris http://www.astro.com/swisseph/ I am currently at the planning scheming and experimentation stage. First I will do the library. But then there is the data. The data is about 60 files not all of which will be wanted by all people. There may be ways of grouping but I am not sure. Perhaps one rpm per file. The Web page says: > For this extended timespan the ephemeris requires 32 Mbytes of ephemeris > files. It would be a shame if this had to repeat for each distro. There may be other projects with even more data. This data is distro and architecture independent. I understand that there should be different rpm per distro because different distros link libraries differently and do other details differently. There could be rpm version dependencies. Perhaps one distro can not understand rpms from another distro as raw data. My question is this is there a lowest common denominator rpm format that can represent pure data (and a few text licensing files) and be understood by all distros? How would you get the build service to produce such rpms? After you produced them how would you get the build service to serve them for all rpm based distros? Same question for debs and the debian based distros? Unrelated question: a while back OBS debian binary repositories were debian compatible but the source repositories were not. Is this still true? -- Paul Elliott 1(512)837-1096 pelliott(a)BlackPatchPanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117

5 4