Does someone know why this is going wrong?
---------- Forwarded message ----------
Date: Wed, 24 Feb 2010 18:32:54 +0100
From: W.C.A. Wijngaards <wouter(a)NLnetLabs.nl>
Subject: Re: [Unbound-users] unbound linking bug with pthreads
-----BEGIN PGP SIGNED MESSAGE-----
Unbound uses http://www.nongnu.org/autoconf-archive/acx_pthread.html
in acx_pthread.m4. It uses configure-style compilation tests to see
what works, and tries -pthread (CFLAGS) and later -lpthread (LIBS). It
does not try both at once.
For me, I end up with -pthread in the CFLAGS. This is included on the
commandline when linking. Perhaps -pthread is enough when linking, or
does it have to be -lpthread ? If so, the configure test to link with
- -pthread should be failing and perhaps a test added to the macro and
If the new system has pthread-config you can set both cflags and libs
with that, no patch required.
On 02/24/2010 05:37 PM, Paul Wouters wrote:
> Fedora 13 will no longer implicitely link in certain libraries. For
> a full description see:
> This is happening with unbound and the pthreads library. So we need to
> pass it a -lpthreads when we are compiling with --with-pthreads.
> I'm not a "configure" expert, so while I do see some tests in configure,
> I don't understand where it remembers the additional -lpthread argument
> which needs to be added to the Makefile's LIBS=
> Currently, on my Linux machine which ran with --with-phtreads, I see in
> LIBS=$(strip -lldns -levent -lrt -lcrypto)
> This is missing -lpthread
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Unbound-users mailing list
You may recall the Marketing team asking for help selecting the F13
talking points last week - thanks to a great many people who
participated, we were able to wrap up the discussion today (which you
can see at
and are happy to announce that the F13 talking points have been chosen.
Here they are! From https://fedoraproject.org/wiki/Fedora_13_Talking_Points:
* 1 For desktop users and everyone
o 1.1 Automatic print driver installation
o 1.2 Automatic installation of language packs
o 1.3 Redesigned user management interface
o 1.4 Color management
o 1.5 NetworkManager improvements include CLI
o 1.6 Experimental 3D extended to free Nouveau driver
* 2 For administrators
o 2.1 BFO
o 2.2 Authconfig UI redesign
o 2.3 Pioneering NSF features
o 2.4 Zarafa
o 2.5 Experimenting with btrfs
* 3 For developers
o 3.1 SystemTap static probes
o 3.2 Easier Python debugging
o 3.3 Parallel-installable Python 3
o 3.4 NetBeans 6.8 first IDE to support entire Java 6 EE spec
* 4 Spins
o 4.1 Moblin Spin
o 4.2 Sugar on a Stick Spin
o 4.3 Design Studio Spin
o 4.4 Security Spin
Now: to finish fleshing them out, we need your help. We're aiming for a
finished product like
https://fedoraproject.org/wiki/Fedora_12_Talking_Points. See the links
to feature pages, heavily hyperlinked descriptions, and catchy one-line
summaries at the end? That's what we need for all the F13 talking points.
If you know cool things about a talking point that should be mentioned,
good resources on it to link to, or otherwise have something to chip in,
please add it to the wiki page
(https://fedoraproject.org/wiki/Fedora_13_Talking_Points); we'll be
cleaning up the final display next week right before the Alpha goes out.
--Mel on behalf of the Marketing team
according to the man-db homepage all/most other major distributions
use a more actively developed manpage suite called man-db, while we only
In a package of mine, "man -l" is used to create a plaintext version of
the manpage, which seems to only work with man-db. Could this be a
Feature for F14 to use man-db instead of man or are there major reasons
not to do this?
Btw. I cc'ed man-owner@fpo.
We tried some new Intel powersaving code in the F12 cycle, but it caused
a range of problems including screen flickering and crashes. I've
reworked this a little and it seems to work on a machine that had
problems in the past, so I'd like to try it again. If anyone with an
Intel GPU (except GMA500, 810, 815 and 830) would like to give the F13
kernels at http://koji.fedoraproject.org/koji/taskinfo?taskID=2009928 a
go and let me know if they result in graphical glitches or hangs that
you don't otherwise have with F13, that would be a great help.
Matthew Garrett | mjg59(a)srcf.ucam.org
> for all maintainers of packages which BuildRequire qt4-devel (or qt-devel,
> but the versioned virtual Provides is preferred): please, when you plan to
> push updates for your packages, ALWAYS CHECK what version of Qt your
> package got built against and DO NOT PUSH your update to stable before
> that version of Qt goes stable! A package built against Qt 4.6 WILL NOT
> WORK AT ALL with Qt 4.5!!! (This is always the case, Qt is backwards- but
> not forwards- compatible.)
FYI, while the above is still sane advice (it's always a good idea to verify
that you aren't building against a newer Qt from a buildroot override!), Qt
4.6.2 is now queued for the stable updates (it was decided in today's KDE
SIG meeting to push the big Qt 4.6.2 / KDE 4.4.0 / SIP 4.10 update set out),
so this particular version bump should no longer be a source of trouble.
Just checked why I've not been able to grab the updates from rawhide and
it looks like the only fedora.repo files in /etc/yum.repos.d is fedora
and fedora-testing. What's happened to the fedora-rawhide.repo files?
I know things were forked a few days back, but didn't realise the
rawhide.repo config would vanish.
Sie können mich aufreizen und wirklich heiß machen!