August 2009 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] renaming for nagios-nrpe
by Christian 06 Mar '10

06 Mar '10

Hi, I am not very happy with naming of nrpe and its sub-pkg. we have nagios-nrpe-client, nagios-nrpe-server While seeing the client pkg I'll be misled to install this pkg on the remote box and vice versa. But the "client" pkg has to be installed on the nagios box. That's why I am thinking of: - nagios-nrpe it is the package to be installed on the remote box. - nagios-nrpe-plugin or nagios-plugins-nrpe just the name will let you associate to install this pkg on the nagios box. What do you think ? Any recommendations are welcome Kind Regards Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 3

[opensuse-packaging] Re: --as-needed and pthread
by Michael Matz 17 Oct '09

17 Oct '09

Hi, [including some random mailing list, so that the text isn't lost :) ] On Thu, 18 Jun 2009, Cristian Rodríguez wrote: > > there are some packages that fail to build because they miss phtread > > symbols. I have always have the doubt about why there is the > > "-pthread" gcc flag... somewhere I read that's the correct thing to > > do, that using -lpthread is wrong, but without explanations. What > > should I use in these cases? I suppose use -lpthread would be the > > equivalent to what they did without --as-needed... but perhaps the > > behavior without --as-needed was already wrong. > > matz is the right person to answer your question, as far as I know, the > right way is using -lpthread instead of -pthread , is that correct ? Nope, -pthread is better than -lpthread (see below). It's completely possible that something is broken with as-needed vs. pthreads. Those cases have to be identified and then worked around (export SUSE_AS_NEEDED=0), or better, analyzed for the root cause. I didn't get the complete thread, only this forward, so I don't know what the nature of the breakage is, so I can give only speculations: I would think that if something with pthread and as-needed breaks it doesn't get exposed as missing symbols or the like (so that apps don't even start) but rather mysterious breakages related to non-thread-aware functions being used even though -pthread was given as compile and link flag. [background] Regarding the explanation of -pthread/-lpthread: Unfortunately the initial threading support for UNIX was a bit like bolted onto the existing (non thread-aware) libc. For various reasons it was decided that users that aren't interested in threading are not supposed to pay the cost of _potential_ thread safety. This cost is mostly associated with locking some shared data structures for libc and the process output (e.g. output of printf() ). Now, given this criteria, there's not much choice. Basically the user has to announce to the system if or if not the application is thread aware, so that it (the system) can chose between thread-aware or non thread-aware functions. This announcement is done by the -pthread flag. The difference to the -lpthread flag is that it is not only a link time flag (saying that the libpthread library has to be put into the dependence libraries) but also a compile time flag. So for compiling .c to .o files for a thread aware program it's necessary to include -pthread into the compile flags. The effect of that option is system dependend. Usually it will result in the compiler defining some preprocessor symbols (_REENTRANT) so that system headers can choose between different implementations of various posix functions (where the API doesn't make a difference between thread-safe and -unsafe functions) and internal data structures. So, for memoizing the difference: -lpthread is a link time only flag, simply telling the linker to include libpthread into the application. -pthread (without the "l") is a link time _and compile time flag_. Because sometimes different code has to be emitted (for the runtime system including libc) for programs supposed to be thread-safe, this can't be announced only at the link phase, the compiler has to know about this. [more magic] Now, for linux there's a bit magic involved. To make the cost for non thread-safe programs really low some routines in libc _are not thread-safe_. That's fine, those programs aren't linked against libpthread, so they have announced to be not interested in threads. libpthread.so provides thread-aware variants of some functions that are also provided by libc itself. For instance open() and friends is such function. The libpthread variant includes some locking for shared data structures. (Apart from these overriding functions it also includes the usual pthread functions, pthread_*, e.g. pthread_spin_lock). How this all works is because ELF symbols resolution rules say so. If an application calls "open" and is linked against libpthread and libc (which both provide a version of "open", one thread-aware the other not) then the dynamic linker will chose the first it finds. Other things (gcc .spec files) make sure that libpthread is linked in _before_ libc when -pthread is given. This can't be ensured for -lpthread, the latter being simply a request for a random other library, as far as the system knows. So only -pthread, not -lpthread, makes really sure that libpthread is linked at the right place vs. libc, so that it can override the non thread-aware functions of it. [less magic] Having said all this, it usually is just fine to simply link against libpthread (via -lpthread) with linux, as long as you don't mention -lc before. This is because most headers don't care about the _REENTRANT preprocessor define, i.e. they don't change their content depending on the flag, and because ELF rules will still make the functions from libpthread be preferred. But for cross-platform compatibility it's important to use -pthread, _not_ -lpthread. And as it's important for others, and at least good under linux, you can just as well use it always if you need. Ciao, Michael.

5 15

[opensuse-packaging] Supplements package with a required version
by Lubos Lunak 08 Sep '09

08 Sep '09

Hello, I have package mozilla-xulrunner191, which can make use of package mozilla-xulrunner191-kde4, but only of a specific version. How do I express that using rpm dependencies? Currently the -kde4 package has "Supplements: packageand(mozilla-xulrunner191:kdebase4-workspace)" to be pulled in when both the main package and the KDE desktop are installed. I however don't know how to express the version dependency, since the -kde4 package does not care what the version of the main package is, but the main package has a version requirement on the -kde4 package, if it is installed. I cannot use Requires in the main package, since -kde4 is optional. If I use Recommends in the main package, I don't know how to recommend the -kde4 package only if KDE is also installed. Is there a way? -- Lubos Lunak KDE developer -------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: l.lunak(a)suse.cz , l.lunak(a)kde.org Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 2

[opensuse-packaging] Skrooge 0.5.0/brp-symlink Build fails
by Sascha 'saigkill' Manns 02 Sep '09

02 Sep '09

Hello Mates, atm i'm getting the following Error. Does anyone know how to fix it? + /usr/lib/rpm/brp-symlink ERROR: link target doesn't exist (neither in build root nor in installed system): /usr/share/doc/kde/HTML/uk/skrooge/common -> /usr/share/doc/kde/HTML/uk/common Add the package providing the target to neededforbuild and Requires INFO: relinking /usr/share/doc/kde/HTML/uk/skrooge/common -> ../common (was /usr/share/doc/kde/HTML/uk//common) ERROR: link target doesn't exist (neither in build root nor in installed system): /usr/share/doc/kde/HTML/sv/skrooge/common -> /usr/share/doc/kde/HTML/sv/common Add the package providing the target to neededforbuild and Requires INFO: relinking /usr/share/doc/kde/HTML/sv/skrooge/common -> ../common (was /usr/share/doc/kde/HTML/sv//common) INFO: relinking /usr/share/doc/kde/HTML/en/doc/common -> ../common (was /usr/share/doc/kde/HTML/en/common) INFO: relinking /usr/share/icons/oxygen/128x128/apps/skrooge.png -> .../../../../pixmaps/skrooge.png (was /usr/share/pixmaps/skrooge.png) INFO: relinking /usr/share/kde4/apps/skrooge/images/logo/l10n/en_US/list_bank.txt -> .../en/list_bank.txt (was /usr/share/kde4/apps/skrooge/images/logo/l10n/en/list_bank.txt) INFO: relinking /usr/lib64/libskgbasegui.so.0.5.0 -> kde4/plugins/designer/libskgbasegui.so.0.5.0 (was /usr/lib64/kde4/plugins/designer/libskgbasegui.so.0.5.0) INFO: relinking /usr/lib64/libskgbankgui.so.0.5.0 -> kde4/plugins/designer/libskgbankgui.so.0.5.0 (was /usr/lib64/kde4/plugins/designer/libskgbankgui.so.0.5.0) error: Bad exit status from /var/tmp/rpm-tmp.7525 (%install) -- Sincerely yours Sascha Manns openSUSE Ambassador openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Project-Blog: http://lizards.opensuse.org/author/saigkill Private-Blog: http://saschasbacktrace.blogspot.com -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 2

[opensuse-packaging] query - Linking in another project.
by doiggl＠velocitynet.com.au 01 Sep '09

01 Sep '09

Hello, I am trying to build the wflogs rpm and have gotten the result back It says - checking for shl_load in -ldld... no configure: error: wfnetobjs-incdir: no directory found, use configure option error: Bad exit status from /var/tmp/rpm-tmp.36404 (%build) References: project -> https://build.opensuse.org/package/show?package=wflogs&project=home%3Adoiggl spec file -> https://build.opensuse.org/package/view_file?file=wflogs.spec&package=wflog… logs -> https://build.opensuse.org/package/live_build_log?arch=x86_64&package=wflog… I know I need to include or depend on Package wfnetobjs. It is located in another persons project -> https://build.opensuse.org/package/show?package=wfnetobjs&project=home%3Ael… Ouestions. ========= 1. How do I link in wfnetobjs to my wflogs project so it can compile. 2. There are possible parameters I can use Parameter switches e.g --with-wfnetobjs-incdir --with-wfnetobjs-library --with-wfnetobjs-libdir An example I have seen in the past is ./configure --with-wfnetobjs-libdir=/usr/include/wallfire/ 3. Where in the spec file does the line go, if so which section ? Any help appreciated Cheers Glenn. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 10

[opensuse-packaging] Rebuilding in OBS
by Magnus Boman 28 Aug '09

28 Aug '09

Hello, For the past months it's been really difficult to contribute to package updates since I only have time to help out on weekends. This boils down to commits going in to oS:F, and my pet project (GNOME:Factory) is basically always blocked waiting for oS:F to build. Trying to build a package locally, is not all that easy, as recently, osc tells me, more often than not, that it can't find a package on a mirror nor in OBS so the local build is aborted. Now, I understand that we want to rebuild packages etc, and I also understand that weekends are the most appropriate time to this. The way OBS rebuilds packages seems a little bit paranoid to me though and I would like to ask the question if we can do it better. So, this is the workflow (AFAIK): 1. I branch a package from G:F, it ends up in my home and basically the content of it is a _link (since I have not changed anything yet) 2. I update the package and commit (now, I have a project.diff) 3. I submit the package to G:F 4. The package is accepted into G:F (G:F will now contain _link and project.diff, while the package in my home is back to being a _link) 5. The package is submitted from G:F to oS:F (and lets say accepted into oS:F). G:F will now be _link, and the package in my home is _link. In oS:F, it's all the files this package contains of Now, what will happen is: * When I do 1, OBS wants to build the package in my home * In step 4 (when package have been accepted), OBS will want to build the package in both my home and in G:F * In step 5, OBS will want to build the package in oS:F, G:F and my home My thinking: In this scenario, my home, G:F and oS:F all use the same build dependencies, so when a package is a _link, can't OBS just copy the content from the linked package instead of having to rebuild it completely in all these different places? Cheers, Magnus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 14

[opensuse-packaging] RE: Adobe Reader 9 (Was: Re: [opensuse-factory] Queries about M6)
by Dominique Leuenberger 28 Aug '09

28 Aug '09

>>> On 8/28/2009 at 7:06, Rastislav Krupanský<rastislav.krupansky(a)gmail.com> >> Installed i586 fine and it works, but Acroread icon missing in SLAB´s >> Aplication Browser. Via Traditional Main Menu is available. Executed in >> terminal without error, described above. > > It´s already there. After log out and log in, icon has appeared in SLAB´s > Aplication Browsare also. (X-posting to -packaging. Those people probably have more knowledge in this domain). Anybody having the trick for me to avoid this glitch in the package? There must be a macro to be executed in the %post section. any help is appreciated. Dominique -- 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] Import of Fedora Packaging Guidelines
by Michal Vyskocil 28 Aug '09

28 Aug '09

Hi all, as you know I wrote a post about Fedora Packaging Guidelines [1]. I was working on it during last three weeks (but a little, so it takes a long time :)) and nowadays I'm ready to import a Fedora's content to en.opensuse.org wiki. Now it is on pack.suse.cz [2]. I also checked that none of that page conflicts with an existing content on openSUSE wiki, so it can be imported easily. Tom Callaway [3] from RedHat confirms me that a Guidelines are under Open Publication License [4] and we can use it for SUSE without restrictions. He was also interested on future collaboration and offers some meeting on LinuxTag - it would be nice if anyone from SUSE will be ready to start a discussion. Before import I'd like to ask: Which pages should be excluded for openSUSE? Some pages seems that they are not interesting for SUSE (like Packaging:OldJPackagePolicy [5], Packaging:SugarActivities [6]). Import it, or don't? Second one is how to edit the text and adapt it for SUSE? Change the existing text or leave it and add a SUSE specifics to the beginning or end of page (as suggests Vladimir)? The second way should help us with synchronizing of changes. After that I'll add a warning [7] on the beginning of every page to prevent that some users will use those guidelines and ask for help with editing ;-) [1] http://lists.opensuse.org/opensuse-packaging/2009-02/msg00043.html [2] http://pack.suse.cz/mvyskocil/fedora-packaging-guidelines/ [3] https://fedoraproject.org/wiki/TomCallaway [4] http://fedoraproject.org/wiki/Legal/Licenses/OPL [5] http://fedoraproject.org/wiki/Packaging:OldJPackagePolicy [6] http://fedoraproject.org/wiki/Packaging:SugarActivityGuidelines [7] http://en.opensuse.org/Template:Warning1 Best regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 26

[opensuse-packaging] URGENT: please review your project.diffs
by Stephan Kulow 27 Aug '09

27 Aug '09

Hi, On http://www.suse.de/~coolo/factory-status.html I try to collect all problematic packages. While it defaults to show only packages currently failing, you can switch to show all problems in the first line. And there a lot of packages where someone accepted it to the devel project reviewing and then didn't submit it for inclusion to the distribution. This is a problem as we're nearing already the 2nd milestone after version freeze and I see tons of such packages ;( Take e.g. python-cairo, a prime example ;( <collection> <request id="15026"> <action type="submit"> <source project="home:lmedinas:branches:GNOME:Factory" package="python- cairo" rev="2" /> <target project="GNOME:Factory" package="python-cairo" /> </action> <state name="accepted" who="vuntz" when="2009-07-21T13:55:05"> <comment></comment> </state> <history name="new" who="lmedinas" when="2009-07-21T13:49:04" /> <description>Update to 1.8.6</description> </request> <request id="16898"> <action type="submit"> <source project="GNOME:Factory" package="python-cairo" rev="9" /> <target project="devel:languages:python" package="python-cairo" /> </action> <state name="accepted" who="poeml" when="2009-08-06T14:44:30"> <comment>reviewed ok.</comment> </state> <history name="new" who="vuntz" when="2009-08-06T00:07:38" /> <description>New upstream version</description> </request> </collection> lmedinas, vuntz, poeml - 3 people worked on this package and still it isn't in 11.2 ;( I understand the problem very well and IMO the work flow just _asks_ for that trouble, but it is as it is - and _everyone_ needs to be aware of it and help others in looking at factory-status.html for packages he worked on and expected them to end in 11.2 Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 6

[opensuse-packaging] another little build service tip
by Stephan Kulow 27 Aug '09

27 Aug '09

Hi, Often I'm asked "what happend to my submit request"? All I do to answer that question (most often the answer is "what submit request?") is: curl -n "https://api.opensuse.org/search/request?match=action/target/@package='bash'" It returns XML format, but it tells you what when where - for all projects where a "bash" package exists. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0