-----BEGIN PGP SIGNED MESSAGE-----
Just did a kickstart install of rawhide and it did not exclude the
packages I had marked with "-name". Is this a known issue?
- - Orion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Does AC_PATH_XTRA (an autoconf macro used in configure.ac to figure out
X library and include paths) cause problems with modular xorg? From the
autoconf info page it looks like it uses xmkmf to work its magic. Is
this information current? If so, this would leave me with several
1) BuildRequire: imake This will bring in xmkmf so that AC_PATH_XTRA
will work. Since xmkmf and imake are on the way out and pkgconfig is on
the way in, this doesn't seem like the right thing to do.
2) In the package's spec, use:
%configure --x-includes/x-libraries=<pkg-config output>
This seems to be driving in the right direction but isn't suitable for
3) Modify the configure.ac to use pkg-config. In order to go upstream,
this would need some sort of conditional in order to do a traditional
AC_PATH_X type check in case of older X releases.
Have other people run into this type of problem in their packages yet?
Any pointers to a better way of handling it?
I't like to request to make the hardlink stage kernel-devel does on every
install optional. It takes a damn lot of time on my not-too-fast machines,
I do not exactly care about the saved disk space, and given the rate of
kernel changes in rawhide there are a lot of wasted CPU cycles there.
There is a /etc/sysconfig/kernel, how about dropping a "HARDLINK=yes/no"
During the FC4 development cycle I mistakenly asked for 2.6.12 to be
included because it "had" the ip_conntrack for ipv6. This was based on
something I read. It turns out the person was misquoting. The USAGI
project was promising this for a patch for 2.6.12. It was never included
at least to my knowledge.
My wish list for FC5 includes the following:
TARPIT target for IPTABLES (I think it is already included).
connlimit (and friends) matching for the kernel, this exists in
documentation but has not yet made the mainstream kernel. Help should be
given to get it there and it should be included.
ip6_conntrack (or whatever it's name is) should be given similar help
and should be included.
Other than that, most of my wishes are ready being addressed. I do think
these are very important for both desktop and server/firewall machines.
"I conceive that a great part of the miseries of mankind are brought
upon them by the false estimates they have made of the value of things."
-- Benjamin Franklin
I have tried to make libnotify / notification-daemon work from python.
I have made this sample, it is works ok, when running as a normal user,
but it dont work when running as root.
It is the same when i am using the
notify-send "foo" "bar"
it works as normal user, but not as root.
Anybody have any clues ???
1) Why isn't /selinux automatically mounted for existing installations?
Without it, rpm installs do not work when rescuing from a
selinux-enabled kernel, such as the one in FC5T2 (because attempts to
set the file context fail).
2) I want to migrate data from an old disk onto a new one. Currently I
have two logical volumes that span both disks, and take up 100% of the
space. I'd like to reduce a lv, in order to migrate the data. Doesn't
seem to work from the rescue CD.
lvresize -r -L -120G /dev/cobra/home2 says:
fsadm: execlp failed: No such file or directory.
Any suggestions? One of the things it's looking at is
/proc/lvm/VGs/cobra.. (/proc/lvm doesn't exist).
3) Unrelated question: When I originally added my sata drive to the
volume group, my kernel would no longer boot. Investigation showed that
sd_mod doesn't get loaded into the initrd, and without it nothing works.
I had to edit mkinitrd to make it put that module in the archive. Why
would that happen?
Version 0.15 (which is the version in the kernel) still has some issues with
specific orinoco type cards. Certain cards return/require a specific header
when doing scan or rfmon (see for example:
Applying this patch to kernel source doesn't work. But I also noticed that
there are other certain incompatibilities as welll that are addressed in the
Agere source. Ok so I am being a little finky ;) but this is also in a sense
a test of what (I am personallY) able to achieve in Linux (learn as you
I will try the hostap drivers to see if that helps.
I am still curious to know though how it is possible to compile a pcmcia
driver that requires the use of pcmcia-cs source for compilitation...
[mailto:firstname.lastname@example.org] On Behalf Of
Date: Tue, 31 Jan 2006 10:18:07 -0500
From: Dan Williams <dcbw(a)redhat.com>
Subject: RE: Compiling pcmcia drivers...
To: Development discussions related to Fedora Core
Cc: 'Pete Zaitcev' <zaitcev(a)redhat.com>
On Tue, 2006-01-31 at 06:56 +0100, Thomas Fischer wrote:
> Yes that would be an opinion if the orinoco driver actually fully
> the complete set of instructions that Agere provide.
> Even with the integration of the latest orinoco version, the current
> is not able to support scanning and doesn't support wpa_supplicant...
Upstream Orinoco has supported scanning for quite a while. Dave Jones
merged that support into the upstream kernel sometime around 2.6.14.
Furthermore, if you really want _everything_ that the orinoco has to
offer, don't use the 'orinoco' driver, use the 'hostap' driver in recent
kernels. That supports both Master mode _and_ wpa_supplicant. In fact,
if I plug in my WaveLAN card, hostap seems to be the default driver
anyway, not orinoco.
What other bits are missing that aren't provided by hostap?
fedora-devel-list mailing list
End of fedora-devel-list Digest, Vol 23, Issue 103