openSUSE Packaging September 2009

packaging@lists.opensuse.org

55 participants
54 discussions

[opensuse-packaging] query - compiling package wflogs.

by doiggl＠velocitynet.com.au

Hello I am trying to compile project called wflogs. Project -> https://build.opensuse.org/package/show?package=wflogs&project=home%3Adoiggl Last log -> https://build.opensuse.org/package/live_build_log?arch=x86_64&package=wflog… spec file -> https://build.opensuse.org/package/view_file?file=wflogs.spec&package=wflog… I have a link to another project called wfnetobjs too (no wfnetobjs rpm installed yet) Last set of wflog errors: configure: error: wfnetobjs-incdir: no directory found, use configure option error: Bad exit status from /var/tmp/rpm-tmp.w8AYXU (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.w8AYXU (%build) System halted. Can someone assist me to compile this package please. 1. I think Ive got to install wfnetobjs rpm but dont know to set that in the spec file. 2. Also I got to do the configure bit with a call like (but unsure how to set in the spec file) # ./configure --with-wfnetobjs-libdir=/usr/include/wallfire/ 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

11 years, 2 months

[opensuse-packaging] renaming for nagios-nrpe

by Christian

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

11 years, 3 months

[opensuse-packaging] Looking for volunteers to fix package dependencies

by Stephan Kulow

Hi, For the ISOs I make sure there is only software on it that can be installed, but for the factory tree there is no such autocheck, so I have to check this manually from time to time. Now I got a little suprise: tons of problems. So I need people to look through the list and either file deleterequests, or bugs. Greetings, Stephan can't install antivir-gui-2.1.10.15-86.2.i586: nothing provides antivir needed by antivir-gui-2.1.10.15-86.2.i586 can't install compiz-devel-0.7.8-40.1.i586: nothing provides kdebase3-devel needed by compiz-devel-0.7.8-40.1.i586 can't install compiz-fusion-plugins-extra-devel-0.7.8-4.20.i586: package compiz-fusion-plugins-extra-devel-0.7.8-4.20.i586 requires compiz-fusion-plugins-main-devel, but none of the providers can be installed package compiz-fusion-plugins-main-devel-0.7.8-12.3.i586 requires compiz-devel, but none of the providers can be installed nothing provides kdebase3-devel needed by compiz-devel-0.7.8-40.1.i586 can't install compiz-fusion-plugins-main-devel-0.7.8-12.3.i586: package compiz-fusion-plugins-main-devel-0.7.8-12.3.i586 requires compiz-devel, but none of the providers can be installed nothing provides kdebase3-devel needed by compiz-devel-0.7.8-40.1.i586 can't install geeqie-1.0beta2.svn20090730-1.6.i586: nothing provides exiftran needed by geeqie-1.0beta2.svn20090730-1.6.i586 can't install git-arch-1.6.4.2-1.6.i586: nothing provides tla needed by git-arch-1.6.4.2-1.6.i586 can't install kdebase3-beagle-3.5.10-26.25.i586: nothing provides kdebase3-workspace = 3.5.10 needed by kdebase3-beagle-3.5.10-26.25.i586 can't install libcompizconfig-devel-0.7.8-7.2.i586: package libcompizconfig-devel-0.7.8-7.2.i586 requires compiz-devel, but none of the providers can be installed nothing provides kdebase3-devel needed by compiz-devel-0.7.8-40.1.i586 can't install obs-api-1.5-6.14.i586: nothing provides rubygem-rails = 2.0.5 needed by obs-api-1.5-6.14.i586 (we have rubygem-rails-2_3-2.3.2-2.5.i586) (we have rubygem-rails-2.3.2-1.5.noarch) can't install ocfs2-tools-1.4.1-23.30.i586: nothing provides ocfs2-kmp needed by ocfs2-tools-1.4.1-23.30.i586 can't install ocfs2-tools-devel-1.4.1-23.30.i586: package ocfs2-tools-devel-1.4.1-23.30.i586 requires ocfs2-tools = 1.4.1, but none of the providers can be installed nothing provides ocfs2-kmp needed by ocfs2-tools-1.4.1-23.30.i586 can't install ocfs2-tools-o2cb-1.4.1-23.30.i586: package ocfs2-tools-o2cb-1.4.1-23.30.i586 requires ocfs2-tools = 1.4.1, but none of the providers can be installed nothing provides ocfs2-kmp needed by ocfs2-tools-1.4.1-23.30.i586 can't install ocfs2console-1.4.1-23.30.i586: package ocfs2console-1.4.1-23.30.i586 requires ocfs2-tools = 1.4.1, but none of the providers can be installed nothing provides ocfs2-kmp needed by ocfs2-tools-1.4.1-23.30.i586 can't install phoronix-test-suite-1.8.1-1.4.i586: nothing provides php5-gtk needed by phoronix-test-suite-1.8.1-1.4.i586 can't install privoxy-doc-3.0.13.90.1-2.4.i586: nothing provides privoxy = 3.0.14 needed by privoxy-doc-3.0.13.90.1-2.4.i586 (we have privoxy-3.0.13.90.1-2.4.i586) can't install python-libbtctl-0.11.1-3.18.i586: nothing provides libbtctl4 = 0.11.1 needed by python-libbtctl-0.11.1-3.18.i586 can't install python-wxGTK-examples-2.8.10.1-1.2.i586: nothing provides python-numeric needed by python-wxGTK-examples-2.8.10.1-1.2.i586 can't install pythoncad-DS1_R36-193.2.i586: nothing provides python-numeric needed by pythoncad-DS1_R36-193.2.i586 can't install rembrand-1.2-113.1.i586: nothing provides librpm-4.4.so needed by rembrand-1.2-113.1.i586 can't install sysbench-0.4.8-99.3.i586: nothing provides mysql-shared needed by sysbench-0.4.8-99.3.i586 can't install sysbench-ctcs2-glue-0.4.8-99.3.i586: nothing provides ctcs2 >= 0.1.6 needed by sysbench-ctcs2-glue-0.4.8-99.3.i586 can't install tin-1.8.3-51.24.i586: nothing provides urlview needed by tin-1.8.3-51.24.i586 can't install vm-dump-metrics-devel-0.2-5.7.i586: nothing provides vhostmd-vm-dump-metrics* = 0.2 needed by vm-dump-metrics-devel-0.2-5.7.i586 can't install xrdp-0.4.1-33.8.i586: nothing provides xorg-x11-server-dmx needed by xrdp-0.4.1-33.8.i586 can't install excalibur-fortress-bean-1.3.1-2.38.noarch: package excalibur-fortress-bean-1.3.1-2.38.noarch requires excalibur-fortress-container-impl = 1.3.1, but none of the providers can be installed package excalibur-fortress-container-impl-1.3.1-2.38.noarch requires excalibur-sourceresolve = 2.2.1, but none of the providers can be installed nothing provides jakarta-commons-httpclient2 needed by excalibur-sourceresolve-2.2.1-2.38.noarch can't install excalibur-fortress-container-impl-1.3.1-2.38.noarch: package excalibur-fortress-container-impl-1.3.1-2.38.noarch requires excalibur-sourceresolve = 2.2.1, but none of the providers can be installed nothing provides jakarta-commons-httpclient2 needed by excalibur-sourceresolve-2.2.1-2.38.noarch can't install excalibur-fortress-examples-1.3.1-2.38.noarch: package excalibur-fortress-examples-1.3.1-2.38.noarch requires excalibur-fortress-container-impl = 1.3.1, but none of the providers can be installed package excalibur-fortress-container-impl-1.3.1-2.38.noarch requires excalibur-sourceresolve = 2.2.1, but none of the providers can be installed nothing provides jakarta-commons-httpclient2 needed by excalibur-sourceresolve-2.2.1-2.38.noarch can't install excalibur-fortress-migration-1.3.1-2.38.noarch: package excalibur-fortress-migration-1.3.1-2.38.noarch requires excalibur-fortress-container-impl = 1.3.1, but none of the providers can be installed package excalibur-fortress-container-impl-1.3.1-2.38.noarch requires excalibur-sourceresolve = 2.2.1, but none of the providers can be installed nothing provides jakarta-commons-httpclient2 needed by excalibur-sourceresolve-2.2.1-2.38.noarch can't install excalibur-fortress-platform-1.3.1-2.38.noarch: nothing provides tanukiwrapper needed by excalibur-fortress-platform-1.3.1-2.38.noarch can't install excalibur-fortress-testcase-1.3.1-2.38.noarch: package excalibur-fortress-testcase-1.3.1-2.38.noarch requires excalibur-fortress-container-impl = 1.3.1, but none of the providers can be installed package excalibur-fortress-container-impl-1.3.1-2.38.noarch requires excalibur-sourceresolve = 2.2.1, but none of the providers can be installed nothing provides jakarta-commons-httpclient2 needed by excalibur-sourceresolve-2.2.1-2.38.noarch can't install excalibur-monitor-2.2.1-2.38.noarch: package excalibur-monitor-2.2.1-2.38.noarch requires excalibur-sourceresolve = 2.2.1, but none of the providers can be installed nothing provides jakarta-commons-httpclient2 needed by excalibur-sourceresolve-2.2.1-2.38.noarch can't install excalibur-sourceresolve-2.2.1-2.38.noarch: nothing provides jakarta-commons-httpclient2 needed by excalibur-sourceresolve-2.2.1-2.38.noarch can't install excalibur-xmlutil-2.2.1-2.38.noarch: package excalibur-xmlutil-2.2.1-2.38.noarch requires excalibur-sourceresolve = 2.2.1, but none of the providers can be installed nothing provides jakarta-commons-httpclient2 needed by excalibur-sourceresolve-2.2.1-2.38.noarch can't install lesspipe-1.60-1.5.noarch: nothing provides dvi2tty needed by lesspipe-1.60-1.5.noarch can't install lucene-contrib-benchmark-2.4.1-2.32.noarch: nothing provides xml-commons-jaxp-1.3-apis needed by lucene-contrib-benchmark-2.4.1-2.32.noarch can't install mockobjects-alt-httpclient-0.09-1.6.noarch: nothing provides jakarta-commons-httpclient needed by mockobjects-alt-httpclient-0.09-1.6.noarch can't install mockobjects-httpclient-0.09-1.6.noarch: nothing provides jakarta-commons-httpclient needed by mockobjects-httpclient-0.09-1.6.noarch can't install setroubleshoot-plugins-2.0.16-2.3.noarch: nothing provides setroubleshoot-server >= 2.0.4 needed by setroubleshoot-plugins-2.0.16-2.3.noarch can't install susedoc-4.2_20090924-1.1.noarch: nothing provides mplus-fonts needed by susedoc-4.2_20090924-1.1.noarch -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 8 months

[opensuse-packaging] Re: --as-needed and pthread

by Michael Matz

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.

11 years, 8 months

[opensuse-packaging] query - opensuse equavilant of elfutils-libelf, elfutils-devel, beecrypt-devel, bzip2-devel, perl-devel

by doiggl＠velocitynet.com.au

I got an expansion error for a project. nothing provides elfutils-libelf, elfutils-devel, beecrypt-devel, bzip2-devel, perl-devel Question: Is there any equivalent opensuse modules to these ones ? project -> https://build.opensuse.org/package/show?package=rpm5&project=home%3Adoiggl Thanks Glenn -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 8 months

[opensuse-packaging] What is the correct way for a maintainer to submit to factory?

by Dave Plater

Hi, I'm trying to work out if it was me or something else that caused the devel project tarball to fail to arrive in factory along with all the other files. 1) Should I disable building before making a submit request? 2) Should the link to the factory package disappear when the submit request is accepted? 3) Does the link need to be present for a new submit request? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 8 months

[opensuse-packaging] One step back with devel projects

by Stephan Kulow

Hi, There is one big problem with the devel projects: some just don't work as it was hoped they would. I expressed the problems before, but basically some projects are just too artificial to create any kind of group feeling for the group of packages. Fortunately some jump into the gap, but I feel we need to discuss some change here. Some of us talked about the problem briefly and the idea that formed out of it is basically this: * We create openSUSE:Factory:Devel as a pool of packages with single maintainers, maintainers can move their packages their if they do not feel they belong in any specific group. In there you only maintain your package, not the rest. * Projects have the choice to move factory packages without maintainer into it up to grab. (I don't think we should leave the TODO project around). I will be maintainer (hopefully with the help of others) of that project to be the interface for new maintainers - avoiding the current "whom to ask of these 100 maintainers" confusion. I don't feel any need to do this before 11.2, but I would like you to give me your ideas about it now so we can implement it shortly after. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 8 months

[opensuse-packaging] audit 2.0 packaging question

by Tony Jones

[I'm not suggesting any of this for OpenSUSE 11.2 ;-)] audit 2.0 has been released. Removal of dead/broken apis with the result that libaudit.so is now bumped to .1 A while ago it was deemed necessary for audit to be split into two spec files, audit.spec and audit-secondary.spec to move python dependancies to prevent huge build system dependancies. Not sure if this is still needed?? If not it would be nice to go back to just one spec as it makes updates a bit easier. To the more important question .... I can osc build v2.0 of audit.spec which produces libaudit.so.1 but when I try to build audit-secondary using previous as the preferred rpms the buildsystem fails to init because su, pam, others require that something provides libaudit.so.0. I have the changes checked into: https://build.opensuse.org/package/show?package=audit-secondary&project=hom… I briefly talked to Marcus on IRC about whether we needed to provide a compat library and he didn't think it was necessary as most/all users of audit-libs are suse system rpms but Adrian seemed to be of the opinion that it was essential for things to build inside the Factory buildservice. Right now my interest is just getting the above location building for test purposes. Not sure if there is an easy way? I can force load the resultant new audit-libs.rpm over an existing system for testing but I'd like to test the -secondary stuff also. Tony -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 8 months

[opensuse-packaging] boinc_client: /usr/include/string.h:218: error: ambiguates old declaration 'char*

by Sascha 'saigkill' Manns

Hello Mates, In file included from cpu_sched.cpp:45: .../lib/str_util.h:41: error: new declaration 'const char* strcasestr(const char*, const char*)' /usr/include/string.h:218: error: ambiguates old declaration 'char* strcasestr(const char*, const char*)' make[2]: *** [boinc_client-cpu_sched.o] Error 1 Does anyone know what to do? -- Sincerely yours Sascha Manns openSUSE Member openSUSE Ambassador openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://saigkill.wordpress.com ClaimID: http://claimid.com/saigkill

11 years, 8 months

[opensuse-packaging] Reverting cairo to 1.8.x for 11.2

by Vincent Untz

Hey, A while ago, we updated cairo to 1.9.2 since it looked like the 1.10 stable release would be there in time for the 11.2 schedule. It turns out we were wrong, so we'd like to go back to the 1.8 branch. Here are some quick pros/cons. Pros: + 1.8.x is a stable branch (1.9.x is unstable) + it will be maintained upstream (1.9.x won't get maintenance updates, so harder to cherry-pick the relevant fixes) + it's what other distros used, so well tested Cons: + it's really late + 1.9.x seemed to work relatively okay for us so far What do people think? 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

11 years, 8 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging September 2009