September 2012 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] "osc mr" gives "Too few arguments" error
by Joseph Mulloy 26 Sep '12

26 Sep '12

I keep running into this issue when I try to update packages in 12.2. I'm following the instructions on the wiki (http://en.opensuse.org/openSUSE:Package_maintenance), but when I get to the "osc mr" step I get a "Too few arguments" error. This is extremely frustrating as this error message is not at all helpful and I'm following the instructions on the wiki. Does anyone know what the problem is? This used to work for me. I'm running "osc mr" from the package directory of my branch. I'm running openSUSE 12.1 with the latest updates installed. jdmulloy@silicon:~/OBS/home:jdmulloy:branches:openSUSE:12.2:Update/branding-openSUSE.openSUSE_12.2_Update> osc mr -m 'Fixed KDM theme for users upgrading from <= 12.1 (bnc#781687)' Too few arguments. jdmulloy@silicon:~/OBS/home:jdmulloy:branches:openSUSE:12.2:Update/branding-openSUSE.openSUSE_12.2_Update> Joseph Mulloy jdmulloy(a)gmail.com -- 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] graphics : exiftool
by Greg Freemyer 26 Sep '12

26 Sep '12

I see that graphics : exiftool was SR'ed 5 weeks ago to have a perl-Image-ExifTool sub-project in the specfile. That is making it very redundant to devel:languages:perl : perl-Image-ExifTool which has similar sub-package structure. The D:L:P version is the devel project for factory and I happen to have issued a SR to it today to make it slightly more recent than the one in graphics. How do we merge those 2 packages and quit doing the work twice? Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 1

[opensuse-packaging] spec-cleaner and Python 'TODO' tasks
by Nelson Marques 26 Sep '12

26 Sep '12

Hi all, I did a small patch (under review) for spec-cleaner the other day (for my own convenience, as between Unity, MATE and Cinnamon it's over 100 packages); I've taken a small look into the TODO file on Gitorious[1] and I was thinking in throwing some more effort regarding the Python tasks for spec-cleaner. I will transcribe them here: * replace %py_ver with %python_version * replace %py_sitedir with %python_sitearch (user might want to change this to %python_sitelib if the package is noarch) print a warning if %py_libdir is found * kill (or just print a warning?) if %py_requires is found: if it's a python module, nothing is needed. If it's not, plain python Requires is what we want. Anyone (Coolo?) confortable with Python Packaging can confirm/comment or suggest that those are the right approaches so I can implement them for Vincent to review? NM -- 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] Build fails because of gzipped symbolic link for SLE11 products
by Johannes Meixner 26 Sep '12

26 Sep '12

Hello, in Printing/ghostscript-fonts/ghostscript-fonts.spec I have --------------------------------------------------------------------------- %install ... # Provide a link to make the Ghostscript fonts also appear in the directory # /usr/share/fonts/ where applications (including X11) search for fonts. # A usr/share/fonts/ sub-directory does not exist in the buildroot: install -d -m 755 %{buildroot}%{_datadir}/fonts ln -s ../ghostscript/fonts %{buildroot}%{_datadir}/fonts/ghostscript . . . %files std ... %{_datadir}/fonts/ghostscript --------------------------------------------------------------------------- For all openSUSE products this works and I get in the binary RPMs the link that I like to have (to fix bnc#778879): /usr/share/fonts/ghostscript -> ../ghostscript/fonts But for SLE11 SLE_11_SP1 and SLE_11_SP2 build fails with: ------------------------------------------------------------------------ [ 61s] + /usr/sbin/Check [ 61s] lrwxrwxrwx 1 abuild abuild 23 Sep 26 13:44 /var/tmp/ghostscript-fonts-9.05-build//usr/share/fonts/ghostscript.gz -> ../ghostscript/fonts.gz . . . [ 61s] + /usr/lib/rpm/brp-symlink [ 61s] ERROR: link target doesn't exist (neither in build root nor in installed system): [ 61s] /usr/share/fonts/ghostscript.gz -> /usr/share/ghostscript/fonts.gz ------------------------------------------------------------------------ It seems /usr/sbin/Check changes both the symbolic link and its target to *.gz and this does of course not exist which is detected then by /usr/lib/rpm/brp-symlink. Is there something wrong with how I make the link in the spec file or is this a bug in /usr/sbin/Check (or elsewhere)? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- 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] Building a single package to support 2 major versions of a dependency
by Darin Perusich 25 Sep '12

25 Sep '12

Hello All, I wasn't sure if this was a build service or packaging issue so I've sent this to both lists. Recently the PostgreSQL package in server:database:postgresql was repackaged to support having both versions 9.1 and 9.2 installed on the same system. This is introducing a problem for PG modules like orafce, pgsql_fdw, and others which when built the resulting libraries were installed in /usr/lib/postgresql. The new packaging lay defines those libdirs as /usr/lib/postgresql91 and /usr/lib/postgresl92. I'm looking for approaches to handle this, hopefully without having lots of duplication. The first approach would be what Debian does, create separate packages for each PG version and rename the packages to postgresql91-orafce and postgresql92-orafce respectively. Another thought is to keep a single package in OBS but setup the spec to create packages for each PG version and name it accordingly postgresql91-orafce and postgresql92-orafce. I don't know if this is possible or how you'd trigger the build but what about having 2 spec's for the package, one that builds for each version? Thoughts? -- Later, Darin -- 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] GStreamer dependencies change in Factory
by Dimstar / Dominique Leuenberger 25 Sep '12

25 Sep '12

Hi all, as announced earlier and as a dependency to GNOME 3.6, we submitted GStreamer 1.0 to Factory, as package name gstreamer. In the past, gstreamer-0_10 provided a virtual symbol gstreamer and gstreamer-0_10-devel provided gstreamer-devel. They were conveniance provides, which had to be removed, as they would; for obvious reasons clash with the actual package called gstreamer and gstreamer-devel. So, if you get a "Nothing provides gstreamer-devel" (which is currently possible, as gstreamer 1.0 is in review mode towards Factory), that means you should switch to use gstreamer-0_10-devel (or, even better pkgconfig(gstreamer-0.10), then you don't have to worry about the actual package names). Or, as an even better solution, get your package up to GStreamer 1.0 (likely discussion with upstreams are needed). There is a rather extensive 'how to port to GStreamer 1.0' documentation available; a bunch of APIs got sanitized and unsane ones have been removed... Hope to have you informed before you wasted all your spare time you don't have on trying to figure out what is going on. Best regards, Dominique / DimStar -- 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] RFC - packaging and changelogs
by Nelson Marques 22 Sep '12

22 Sep '12

Dear all, ChangeLog formats are not the same across the project; some projects are more demanding, others aren't; I've seen a royal mess in many, I've found others way to strict and speaking for myself, I find it very uncool that we can workout an update on package in 10 minutes and wast 4 or 5 times more with the changelogs (entries in .changes) than doing the technical update. Now it would be nice that all the packaging gurus out there could get some time during OSC and probably make a BoF or some discussion about trying to bring a unified procedure accross the project. Honestly if we want people to get in the workflow or help us out, I find that hard to accomplish when the technical details take way much less to do perform than the changelog entries. So, please whoever has the power to change things and work towards this, please take the lead so that if one can help, it doesn't has to follow different ways of working; If you want to increase the precision of the changelogs, cool, if you want to make it more 'loose' nice... A few situations to consider: 1. A package that hasnt been updated for a few releases: + making tens of entries, so that they get squashed in the bottom sounds uncool; + if you want precision on changelogging, then remove that squash and lets us use 100 lines or more in the changelog entry, otherwise don't ask for precision. 2. Format and documentation: + Just consider documenting the whole process so that we can learn to make the entries project wide; If this means that 99% of people will face more picking situations, then too bad. But we need this stuff sorted. We can't have personal reviews taking the heat all by themselves without being able to refer to a unified method/documentation. Honestly consider this seriously and someone make a stand and raise a crusade to provide people the tools/guidance they need. So far it's hillarious to fix/upgrade/update a package in a few minutes, and then waste countless hours with the changelog. Some people may like to masturbate while writting changelogs, I don't... specially because for the vast majority of the cases, the NEWS file does provide exactly a duplicate of the entries... For the defenders of 'rpm -q --changelog'; sure it's nice in runtime, but if the package is properly packaged, then you should have NEWS on documentation... Which ends up being pretty much the same. This is just a personal concern, which probably others may share. If I have to improve this and learn this stuff, I only want to do it once, not for all bloody projects out there... If old habbits have to die, then they better die once and for all. NM -- 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] [RFC] gpg-upstream-keys: Build time source GPG signature verification
by Stanislav Brabec 21 Sep '12

21 Sep '12

Hallo. I wrote a simple tool that provides build time GPG signature verification. It could prevent need for tarball contents verification and still being safe. Submit reviewers will just review changes in the spec files and patches, and especially verifies, that GPG verification command is not removed without rationale. How it is done: gpg-upstream-keys package collects signatures valid for verification of particular packages sources: gpg-upstream-key-*.key: Contains approved signing keys. gpg-upstream-keys.packages: Defines mapping package -> signing keys There is a tool for simple key extraction and verification and macro for simple integration to spec files. Prepare new signing key before first use: gpg-upstream-keys-tool --verbose [--package=PACKAGE] --prepare ID It will tell you how to edit gpg-upstream-keys.packages and gpg-upstream-keys.spec. Usage in packages would be straightforward: BuildRequires: gpg-upstream-keys %prep %gpg_verify %{S:1} %setup -q Note: %{S:1} is the signature, not the tarball. Here is a proof of concept and two upstream-signed packages: https://build.opensuse.org/project/show?project=home%3Asbrabec%3Abranches%3… Simple man page is added. Comments are welcome. Proposed policy: Package updates will be straightforward, as long as the same signing key is used. Reviewers should make special attention to submit that contain "-%gpg_verify" in the changes log. Any addition to gpg-upstream-keys should be carefully verified. Any change in gpg-upstream-keys would need to be double-verified. Problems: How to solve key expiration? Probably accept expired keys to prevent unexpected future failures. How to solve key expiration extension? Probably provide a way to re-import keys by trusted user. How to solve key revocation? Probably extend the tool to not accept revoked keys. But later it is a complicated task. Not only that the keys package would need update, but also all packages that contain revoked signatures would need update, otherwise the build fails. On the other hand, keeping the key in the ring is a security risk: The previous version signature before revocation time may be OK, but next version may be malicious. (And GPG does not implement trusted time stamps.) I did not found a way, how to prevent following warning: gpg: WARNING: Using untrusted key! (I do not want to use web of trust, but instead of it fully trust all keys in the locally stored read-only keyring.) -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- 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] Python modules
by Nelson Marques 21 Sep '12

21 Sep '12

Hi all, I've submitted a new package to devel:languages:python, python-beautifulsoup4 after consulting the maintainer from python-beautifulsoup. Currently python-beautifulsoup requires Python >= 2.6, and this includes Python 3. For the Python 3 builds, there's some wizardry required to convert a few bits of code, which suggests a new package from the same source, since it's a sweet package for either Python2 or Python3. I don't really care if Python 2 is slowly disappearing. What would be best to proceed on this and how to differentiate the packages ? Any help will be most welcome. NM -- 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] baselibs / -32bit packages
by Nelson Marques 20 Sep '12

20 Sep '12

Hi, I need to create a -32bit package for one of my packages; Anyone can give me a quick example on how to do this? (this is for my infinality freetype package) NM -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3