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
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
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
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.
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
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
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
[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
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
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