June 2011 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] php5-pear-phpunit-PHP_CodeBrowser gives me E: file-contains-buildroot
by Ralf Lang 24 Jun '11

24 Jun '11

Hi, the following happened before with other packages (which I then packaged without fancy macros which lead to some factory complaints) but this puzzles me once again: RPMLINT report: php5-pear-phpunit-PHP_CodeBrowser.noarch: W: no-manual-page-for-binary phpcb Each executable in standard binary directories should have a man page. php5-pear-phpunit-PHP_CodeBrowser.noarch: W: files-duplicate /usr/share/php5/PEAR/data/PHP_CodeBrowser/templates/img/treeToggle- extended.png /usr/share/php5/PEAR/data/PHP_CodeBrowser/templates/js/jquery.sidebar/css/codebrowser/inject- right.png php5-pear-phpunit-PHP_CodeBrowser.noarch: E: file-contains-buildroot (Badness: 10000) /usr/share/php5/PEAR/PHP_CodeBrowser/CLIController.php php5-pear-phpunit-PHP_CodeBrowser.noarch: E: file-contains-buildroot (Badness: 10000) /usr/bin/phpcb Your file contains traces of $RPM_BUILD_ROOT. (none): E: badness 20000 exceeds threshold 1000, aborting. 2 packages and 0 specfiles checked; 2 errors, 2 warnings. The original file does not contain static paths but relative ones (../) After rpm packaging they contain static paths and generate errors Why is that? I think rpm imagines these references to runtime dependencies are compile-time objects in the buildroot. How to circumvent this? -- Ralf Lang Linux Consultant / Developer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] Advice for packaging Jinchess
by Bruno Friedmann 23 Jun '11

23 Jun '11

Hi All. I've a request to package Jin [1] which is a java frontend for online chess game servers. The project is gpl, no a problem with that. Now I've two questions, can we put and package the official .jar published by the author ? [3] contain all needed to run the game. Main deps is java (the sun one is recommended) Or to be accepted, it would be preferable to rebuild entirely from sources (the author mention that) [4] but seems to not be in favour of. In case of it can be accepted in obs. which layout in the filesystem would be the best /opt/jinchess ? Thanks for your time [1] http://www.jinchess.com home page [2] http://jin.sourceforge.net devel project [3] http://prdownloads.sourceforge.net/jin/jin-2.14.1-unix.tar.gz?download [4] http://jin.cvs.sourceforge.net/viewvc/jin/jin/release/build.xml?revision=1.… -- 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 For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] Policy change for factory
by Stephan Kulow 22 Jun '11

22 Jun '11

Hi, It wasn't enforced for quite a while, but now it's also gone from rpmlint so I should make more people aware: please don't recompress tarballs unless it saves >1MB for download. The original policy was necessary because SUSE shipped a DVD, but by now we ship 3 DVDs if people order source DVDs and one more doesn't really matter (as the one ordering has to pay it anyway - but such orders are still very rare ;) And if you recompress your tarball, using bz2 might not be the best choice, xz might save even more - many upstream projects change to it as default. What will become policy sooner or later is that you should not have incorrect source URLs behind Source*, so _if_ you have to recompress, don't lie in the Source line, but put the original tar as comment and use local file names in Source: Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 2

Re: [opensuse-packaging] Packaging policy for systemd .unit file - Proposal
by Frederic Crozat 21 Jun '11

21 Jun '11

Le mardi 21 juin 2011 à 09:12 +0200, Ludwig Nussel a écrit : > Frederic Crozat wrote: > > Le lundi 20 juin 2011 à 17:35 +0200, Frederic Crozat a écrit : > > > Le lundi 20 juin 2011 à 17:07 +0200, Ludwig Nussel a écrit : > > > > Frederic Crozat wrote: > > > > > [...] > > > > > Here is a proposal I plan to submit upstream if it is fine with people > > > > > here. I've reused Michael Schröder proposal from FOSDEM 2006, adapted to > > > > > systemd. > > > > > > > > > > For openSUSE, we could modify slightly this proposal to call % > > > > > fillup_and_insserv / %stop_on_removal / %restart_on_update when package > > > > > hasn't migrated to systemd (I didn't add this part to systemd proposal, > > > > > since it is distro specific) and would keep compat for current users of > > > > > service_add / service_del_preun / service_del_post > > > > > > > > > > > > > > > (proposed at fosdem 2006) > > > > > %service_add() > > > > > if [ "$1" -eq 1 ] ; then > > > > > # Initial installation > > > > > /bin/systemctl daemon-reload >/dev/null 2>&1 || : > > > > > fi > > > > > > > > > > %service_add_enabled() > > > > > if [ "$1" -eq 1 ] ; then > > > > > # Initial installation > > > > > /bin/systemctl enable %{1}.service >/dev/null 2>&1 || : > > > > > fi > > > > > > > > There are some packages that directly package the symlink in e.g. > > > > multi-user.target.wants. I suppose that shouldn't be done in favor > > > > of the macro then? > > > > > > Good question. I guess this should be discussed with upstream folks. > > > > I can see one big issue, mostly in migration : > > systemctl enable (or disable) only works if systemd is running. So, if > > you are installing a package which tries to enable a .service and if > > systemd isn't running (old init or upgrade for 11.4), systemctl won't do > > anything :( > > > "systemctl enable" could simply be replaced with a "ln -s" call I suppose. > OTOH the package could just as well simply include the symlink in > %files then. Yes, both are possible (and using "ln -s" is probably better since it will work on an upgrade). Adding to %files will ensure removing the link will be detected by rpm -V. Probably worth discussing with upstream. -- Frederic Crozat <fcrozat(a)suse.com> SUSE -- 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] OBS adds extra unneeded dependency to a package
by Ilya Chernykh 20 Jun '11

20 Jun '11

Hi! I am trying to package kderadiostation: https://build.opensuse.org/package/show?package=kderadiostation&project=hom… The package includes a library libkradiopart.1 But when trying to install this package zypper and Yast say that it needs libkradiopart.1 which is not provided by any package. After installation if to break the dependency, the application works well. So why OBS adds to this package a dependency on a library which is already included inside itself and does not add the same library to Provides? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 5

[opensuse-packaging] Linux shared library policy
by Dave Plater 19 Jun '11

19 Jun '11

I'm relatively new to Linux, a friend gave me, I think 5, SuSE 7.3 cds and it was the splash screen on installation showing the staff and workplace that really got to me and Win xp didn't appeal to me after 98se. The packaging list would have seen the Packman email I cced there about mjpegtools, I was very tired then now my head is clear. During my period as a maintainer I've learned quite a bit about Linux internals and rules that are applied to the way that packages are made up. One of these is the shared library policy which I've seen practical examples of it's necessity. I've also just discovered something which appears to me to be a rot setting in the Linux development world or possibly these are two exceptions, one old and one new or maybe somebody like me is needed, a fresh "outsiders perspective" from the inside. I've learned the meaning of ABI (application binary interface), it's the address offset (from the base address the binary is loaded into) of the various functions that shared libraries offer to their calling programs. Maybe it's a coincidence that I just happen to be trying to turn a new not yet submitted library package into a proper shared library, as I said I lack Linux / Unix experience so please correct any misconceptions I have, then my old enemy mjpegtools surfaces as version 2.0.0. Both these packages are the "anti openSUSE shared library naming policy" and what appears to me to be a trend to deviate from consistency in shared libraries, Mjpegtools appears, from what the developer has said (note appears means speculation not certainty) to have undergone a "not small" ABI change and that would mean a bump in the major so version, I've studied libtool and other library build aspects since making openCOLLADA and I'm not sure without digging through piles of references but I think libtool can actually detect these ABI changes. Ok the punchline is mjpegtools's libraries are named thus and have been for at least the last three versions, I've downloaded an entire history of mjpegtools source rpms to find out where this came from, mjpegtools supply a spec file which ours is based on, I only use supplied spec files for reference nowadays, after I've made an original myself in my own words so to speak : /usr/lib64/liblavfile-2.0.so.0 /usr/lib64/liblavfile-2.0.so.0.0.0 /usr/lib64/liblavjpeg-2.0.so.0 /usr/lib64/liblavjpeg-2.0.so.0.0.0 /usr/lib64/liblavplay-2.0.so.0 /usr/lib64/liblavplay-2.0.so.0.0.0 /usr/lib64/liblavrec-2.0.so.0 /usr/lib64/liblavrec-2.0.so.0.0.0 /usr/lib64/libmjpegutils-2.0.so.0 /usr/lib64/libmjpegutils-2.0.so.0.0.0 /usr/lib64/libmpeg2encpp-2.0.so.0 /usr/lib64/libmpeg2encpp-2.0.so.0.0.0 /usr/lib64/libmplex2-2.0.so.0 /usr/lib64/libmplex2-2.0.so.0.0.0 The new package I referred to earlier uses, taken from one of the three libraries, "libserd-2.0.0.so.0.0.0" ok this is easy, once I've named the libraries container package "libserd-2_0_0-0" for the "untechnical" users, this is why some packages have such strange and ugly names. The author of the new package has instructions that this naming is to ensure that his shared libraries future versions can be installed in parallel, I've read about this somewhere, oh yes the shared library policy but doesn't that refer to the digits after the ".so" oh yes that's what they're there for. (I apologise to those of you that don't like sarcasm but it's the only thing I have to anchor my sanity) Maybe this is the root cause of gstreamer never actually functioning 100%, I've switched back to obsolete backend-xine for the umpteenth time after trying gstreamer again. One thing I have a wealth of experience with is trouble shooting hardware and embedded program bugs in things designed and produced both by myself and by third parties and the worst kind of bug is the type produced by a slight intermittent clock jitter or for that matter an infrequent transient from an undefined logic state. Worst still is a part of a program that loses sync and enters address space that is undefined but by sheer luck stumbles back into sync, this is actually extreme bad luck if you are talking about life support systems or for those of you that value money over life a slot machine or vending machine. This can go unnoticed for ever or irritate the life (excuse the pun) out of the user. Such a bug can be caused by an ABI missmatch, which is the reason why I'm so vocal about software using the exact libraries it was built with, I was involved in a heated debate (wasn't really a debate because my opinion was ignored) about obsoleting a Packman devel package with a ficticious version number to prevent it from being paired with an openSUSE built library package because it introduces an element of uncertainty which to me is an undefined logic state and capable of introducing the "hidden bug" I described earlier. Is this a new trend in the Linux world? Are we eventually going to drop those pesky digits after ".so"? One thing that ms windows and osx have going for them is singularity which makes regularity easy, opensource is a collaboration of many spread out all over the world, something my generation wanted with a passion when we were young and wanted to unite the whole world in peace. This is why the shared library and naming conventions are so important, otherwise paths will deviate and confusion will creep in. As far as the new package is concerned, it's a small package and all three libraries build in one online build service page or the blink of an eye. I'm busy learning the "waf" build system, quite good library build support and quite easy to get the libraries in shape. I just have to get the named header directories to fit in and allow shared devel packages and then I will, in the best possible way (I would hate to be in the position of the debian packager who clashed with Jorge Schilling) present my patches and explain the library packaging policies of Linux distributions and how grateful I would be if could call the library containers "libserd0" and not "libserd-2_0_0-0" (sarcasm tried to creep in there). If he doesn't want to due to ego maybe, to be a good musician or for that matter outstanding at anything you have to have a large ego, I know I've got one myself, I'm a performer and I've dealt with musical performers in the past, in fact a large percentage of my acquaintances .are musicians, sound engineers or both, larger than the technical portion. I wonder why I ended up maintaining multimedia. Why has mjpegtools been allowed to abuse library naming. I filed a bug with them thinking it was a problem with the 2.0rc1 version but the developer I was communicating with didn't seem to understand what I was trying to say. I'm going to continue to work on patching mjpegtools to have correct versioning, it's good practise and the right thing to do in my mind and as I pick up experience I will patch every other package I stumble upon that has this disease and eventually be able to build libraries in my sleep, this frees time to do other things like fixing somebodies computer, which is where I'm supposed to be now. What is going on? I'm hoping that those of you who've been around Linux for a while can tell me. If the answer is "it doesn't matter" I'm going to relentlessly campaign for a serious change in the openSUSE shared library policy and silently lose faith in the future of Linux. Now go back up the page and look at the part that says "gstreamer doesn't quite work 100%". Can somebody please give me a pointer on how to detect ABI differences between library versions. I know how to look for bad linking so far, maybe these are just isolated incidents.] Thanks for your time. Dave Plater -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 7

[opensuse-packaging] What´s wrong with my spec-file?
by Kim Leyendecker 19 Jun '11

19 Jun '11

Dear packagers, I created a spec-file for my app according to this reference: http://www.rpm.org/max-rpm/s1-rpm-specref-scripts.html My app should be build with OBS, and here´s my spec-file: https://build.opensuse.org/package/view_file?file=diav.spec&package=diav-3.… The reference says, that I can use every valid sh-command, so, I used the command to decompress the source tarball and the "make" command for building from sources. Oh, I think, I forgot something like configure? What do you think? thanks in advance, -- Kim Leyendecker kdl(a)k-dl.de.vu openSUSE Ambassador, openSUSE Wiki DE Send from my notebook -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 4

[opensuse-packaging] HTTP Error 400: remote error lilo no logfile
by Per Jessen 17 Jun '11

17 Jun '11

I'm upgrading lilo - 23.2 has a fix needed for making current Factory boot. > osc results lilo . SLE_11_SP1 i586 (unpublished) U SLE_11_SP1 x86_64 (unpublished) . openSUSE_11.3 i586 (unpublished) U openSUSE_11.3 x86_64 (unpublished) . openSUSE_11.4 i586 (unpublished) . openSUSE_11.4 x86_64 (unpublished) . openSUSE_Factory i586 (unpublished) . openSUSE_Factory x86_64 (unpublished) U= unresolved. When I try to get the buildlog: ...Base:System/lilo> osc buildlog openSUSE_11.3 x86_64 Server returned an error: HTTP Error 400: remote error lilo no logfile remote error: lilo no logfile ...Base:System/lilo> osc buildlog SLE_11_SP1 x86_64 Server returned an error: HTTP Error 400: remote error lilo no logfile remote error: lilo no logfile I'm stuck. -- Per Jessen, Zürich (17.2°C) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 9

[opensuse-packaging] Pushing python 3.2 to Factory?
by Vincent Untz 17 Jun '11

17 Jun '11

Hi Jan, Is it planned to push python 3.2 to Factory soon? To be honest, I don't care much about 3.2 itself, but the package in the devel project has the nice rpm macros, and it's harder to package anything for python3 without those... Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

7 13

[opensuse-packaging] glibc-devel-static coming to Factory
by Andreas Jaeger 17 Jun '11

17 Jun '11

I'm submitting now to Base:System a glibc with a glibc-devel-static subpackage, so for static linking you need to add to your spec files: BuildRequire: glibc-devel-static this was suggested at bnc#655261. if you see serious problems, please speak up, Andreas -- Andreas Jaeger, Program Manager openSUSE aj(a){novell.com,suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 5