sysconfig ifcfg-* support for running custom post-up scripts per interface?
by Pasi Kärkkäinen
Hello,
Has there been any plans to support running custom post-up scripts for each interface, after "ifup <interface>" ?
Debian allows you to specify:
iface eth0 inet static
..
post-up /etc/network/if-up.d/fw.start
I'm looking for something similar for rhel/fedora.
Any ideas?
Maybe something like POST_UP="/path/script" in /etc/sysconfig/network-scripts/ifcfg-int
Thanks!
-- Pasi
13 years, 11 months
Harmless KDE feature upgrades - yeah right
by Juha Tuomala
Ironically it happened again, just now when these FESCO threads
are still warm.
My desktop gui processes leak enough mem that I need to restart
couple times a week or system will run out of memory. Today
I started with updating the F11 with yum. During the update,
I noticed that it's pulling in the kde-4.4.0, scary. Then reboot.
Now when I logged in, noticed that desktop has really changed
quite a bit, some visual stuff even fixed.
Then I tried to start kmail to start working. It starts, asks
passwords, whines something about Akonadi which i don't use and
then crashes/exists.
kmail(4465)/kio (KIOConnection)
KIO::ConnectionServer::listenForRemote: Listening on "local:/tmp/ksocket-tuju/kmailRj4465.slave-socket"
kmail(4465)/libakonadi Akonadi::Control::Private::exec: Could not start/stop Akonadi!
kmail(4465) main: Unable to start Akonadi server, exit application
kmail(4465)/kdecore (KConfigSkeleton)
KCoreConfigSkeleton::writeConfig:
(gdb)
This is exactly kind off stuff I don't have time now to solve,
since I need to work. If such upgrade would have been put to
next coming release, I could have upgraded when I have time,
some weekend - it would not interrupted my working and ruin my
day.
For all those who say that "latest stuff is the reason why
I use Fedora!!!1", there is rawhide for you.
For a lot of people, this kind of breakage is exactly the reason not
to switch from windows/mac to Fedora.
Yes, I'm writing this with Alpine... handling pdf attachments and
doing invoicing with it is going to be fun.
KDE SIG, you need to re-think that proposal again.
Tuju
--
Ajatteleva ihminen tarvitsee unta.
13 years, 11 months
devkit-power-daemon broken?
by Ankur Sinha
hey,
I've had this issue for quite a while now.
I have a HP pavilion laptop that runs a Fedora 12 (up to date) and vista
(the original that came with the laptop). I'm using GNOME as of now.
When a power cut occurs, the power applet continues to show the adapter
plugged in,and battery at 100%. This restrains my system from
hibernating etc correctly, or even dimming display when ac power is
removed.
I've already filed a bug here.
https://bugzilla.redhat.com/show_bug.cgi?id=554363
To confirm that there is indeed a bug, I've checked using acpi-tool,
htop all of which give correct values of battery and that there is no ac
power attached.
As the bugreport says, killing /usr/libexec/devkit-power-daemon and re
running it corrects the status, however it's irritating to have to do
this every time a power cut occurs (if im around that is).
Can someone think of a fix or at least a work around for the time
being?
--
regards,
Ankur
- FAS : ankursinha ; franciscod @ Freenode
- gpg --keyserver pgp.mit.edu --recv-keys 5E9BF638
13 years, 11 months
Macbook Pro 13.3" (5,5) Fedora 12 notes
by Jon Masters
Folks,
In case this helps anyone else setting up a Macbook Pro 13.3 model 5,5.
1). Installation proceeds normally. You may want to install rEFIt to
allow dual booting with Mac OS X, in which case Anaconda should oblige
by placing grub on the partition of your /boot partition. You then only
need to run gptsync by choosing the Partitioning Tool next boot.
I took my new Macbook apart and upgraded the disk to a 500GB model from
the tiny one it came with. They wanted a small fortune for a non 7200K
drive upgrade, so I laughed. My partitions are as follows:
1: EFI (hidden in OSX)
2: OSX (100GB)
3: Linux Boot (1GB)
4: Linux LVM (swap,root,100GB)
5: Shared (hfsplus,100GB)
6: Data (2ext4,200GB)
The first three partitions are mapped to the MBR style GRUB is looking
for following a gptsync within the EFI booter tool.
2). The new install has no networking because the 432b reversion part is
unsupported by the b43 Open Source driver (they are working on it). You
will need to download the "wl" driver from Broadcom. It won't load out
of the box because it can't see the device. For the moment, the
following hack in /usr/local/bin/wl_hack.sh (called from /etc/rc.local)
suffices to load (this is weird, seems the second load/unload results in
some ACPI power state change and the device will then show up randomly):
#!/bin/sh
# for some reason we don't see the bcm part unless we unload/reload
b43/wl.
modprobe b43
modprobe -r b43
modprobe wl
modprobe -r wl
modprobe b43
modprobe -r b43
modprobe wl
It may still drop off the network from time to time. An upstream driver
will be really helpful when that is available. I will need a backport of
a future stable wireless tree to 2.6.32 since I am not planning to
upgrade my X drivers for the incompatible ABI in future nouveau.
3). Sound won't work out of the box, but it will (including the
headphone detection) if you do the following:
rpm -e alsa-plugins-pulseaudio
Then alsamixer will show all of the channel options, which you should
set to 100% volume for now. The GNOME volume controls will now work. Add
"alsa-plugins-pulseaudio" to and exclude line /etc/yum.conf to prevent
it ever getting installed again. Also add "kernel" to that line while
you're at it if you'll be fixing the mouse in the next step. I like to
build my own kernels for Fedora so I generally forbid it installing.
4). Out of the box, the mouse experience is horrible. You may want to
create an xorg.conf file (using Xorg -configure), but there is a better
way to configure the mouse on recent systems. Place the following
in /etc/hal/fdi/policy/20thirdparty/10-synaptics.fdi:
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.touchpad">
<!-- To add custom options for the touchpad, modify the examples
below
to suit your needs. The available options are listed in the
"synaptics" man page. After modifyfing this file, you must
restart HAL. Check the output of lshal whether your
modifications
have been merged successfully.
Note: Options must always be type "string".
The following examples enable left, right, middle clicks on
single, double, triple finger tapping, respectively.
<merge key="input.x11_options.TapButton1"
type="string">1</merge>
<merge key="input.x11_options.TapButton2"
type="string">3</merge>
<merge key="input.x11_options.TapButton3"
type="string">2</merge>
-->
<merge key="input.x11_driver" type="string">synaptics</merge>
<merge key="input.x11_options.SHMConfig"
type="string">On</merge>
<merge key="input.x11_options.TapButton2"
type="string">0</merge>
<merge key="input.x11_options.TapButton3"
type="string">0</merge>
<!-- Not needed with the hacked up 2-finger-click-to-drag-driver
<merge key="input.x11_options.ClickFinger2"
type="string">0</merge>
<merge key="input.x11_options.ClickFinger3"
type="string">0</merge>
-->
</match>
</device>
</deviceinfo>
That will turn off the most annoying "TapButton" options and tell X to
start the synaptics touchpad driver with the ability to dynamically tune
the driver using a shared memory mechanism. This enables "synclient".
You need a fixed bcm5974 mouse driver (with the attached patch - cleaned
up version to follow) that correctly supports two finger click-and-drag.
I have modified an existing patch for 2.6.32 kernels and will post a
kmod in due course. With that patch enabled you won't need to turn off
the ClickButton support and can both drag and right/middle click.
5). The gnome-power-manager gets a little confused sometimes. Make sure
it is always showing at least (sometimes it doesn't notice the battery
even though that is showing in lshal, etc.):
gconftool-2 -s -t string /apps/gnome-power-manager/ui/icon_policy always
You will also need to chvt or similar to/from another VT on resume in
order for the display to wake up. The HAL scripts specifically disable
quirks in the case of KMS because they believe it will always work. I
have tried hacking up the low level /usr/libexec/scripts/linux/ bits but
that isn't working, so I need to find out what I am missing. For the
moment, I switch to/from another VT on resume.
6). The backlit keyboard and controls aren't showing up or working. I
can live without these until I get chance to figure that out.
7). The webcam isn't working out of the box and nor is bluetooth. There
are instructions online covering these.
Once I configured my themes, set SELinux to permissive, and made a few
other personal taste quirks, the experience so far isn't too bad.
Jon.
13 years, 11 months
should man-pages-* have Requires: man?
by Ivana Varekova
For now in fedora there are 11 packages which contains language
mutations of man-pages (man-pages-{cs,da,de,es,fr,it,ja,ko,pl,ru,uk})
and man-pages package.
Only 2 of them (man-pages-es, man-pages-it) requires man package. I
think man dependences should be consistent in all man-pages* packages.
From my point of view man dependency should be in all of them.
Any ideas?
Ivana Hutarova Varekova
13 years, 11 months
Please move your ABRT bugs upstream
by Christoph Wickert
A while back I was complaining about how the KDE SIG handles bug
reports. One could certainly argue that closing everything UPSTREAM
doesn't help to track bugs in Fedora, but on the other hand the bugs are
at least submitted to the original developers.
When I receive a bug report I have a look at it and if it contains all
necessary data, I forward it to upstream's bug tracker. Most of the time
the developers are very thankful about the reports and especially the
backtraces. Looking at the bugs I filed I see that nearly nothing gets
forwarded upstream. :(
We have this nice ABRT tool now, so please let the bug reports our users
collect not be useless and forward them upstream cause that's where they
belong. We are not collecting these reports to let them rotten in our
bugzilla and get them closed by the bugzappers. This is frustrating both
for the users as well as for the developers.
Please, dear maintainers, take care of your ABRT reports and forward
them if you cannot handle them yourselves!
Thanks a lot,
Christoph
P.S.: Now that we gather all these data, do we need a general policy for
it? Should the bugzappers take care of forwarding bugs?
13 years, 11 months
Fwd: Btrfs compression
by Valent Turkovic
How to recompress data already on btrfs partition?
Cheers.
---------- Forwarded message ----------
From: Valent Turkovic <valent.turkovic(a)gmail.com>
Date: Thursday, April 29, 2010
Subject: Btrfs compression
To: Community support for Fedora users <users(a)lists.fedoraproject.org>
Hi, AFAIK btrfs compression is enabled via mount option. I'm now
installing Fedora 13 beta on / partition formated As btrfs. During
install there is no option for compression. If I add compress option
after install is there a way to compress data that was saved during
the install?
Cheers!
--
pratite me na twitteru - www.twitter.com/valentt
blog: http://kernelreloaded.blog385.com
linux, anime, spirituality, windsurf, wireless, ronjenje, pametne kuće, zwave
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turkovic(a)hotmail.com
--
pratite me na twitteru - www.twitter.com/valentt
blog: http://kernelreloaded.blog385.com
linux, anime, spirituality, windsurf, wireless, ronjenje, pametne kuće, zwave
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turkovic(a)hotmail.com
13 years, 11 months
Fedora 13 Release Candidate phase coming soon
by Jesse Keating
We will be entering the Release Candidate phase of Fedora 13 development
in one week's time.
What does this mean? It means that we will have hopefully reached a
point where all known release blockers¹ have been fixed and we are read
to compose the final release tree. The only changes accepted from this
point on will be changes deemed important enough to delay the release
should we not get them fixed in time. It also means we will be opening
up bodhi for preparing 0-day updates for Fedora 13, changes which are
not important enough to delay the release. This means that updates put
into bodhi and marked as "stable" will go to the stable updates
directory, not Fedora 13 itself.
If you have a change that you feel is critical to the release, make sure
your bug blocks F13Blocker so that it will get the attention of the
release team. Builds that fix issues on the blocker will be hand picked
into the release and will bypass the bodhi stable phase.
This is the first time we'll be doing this phase of the development in
the new No Frozen Rawhide style of development, so there are bound to be
a few hiccups, and we are still drafting a wiki page to explain this
phase of the development. Please bear with us as we work together to
get Fedora 13 out the door.
¹)
https://bugzilla.redhat.com/showdependencytree.cgi?id=507681&hide_resolved=1
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
13 years, 11 months
gpsd update
by Miroslav Lichvar
I'd like to update the gpsd package to the latest version 2.94. If
there will be no objections, probably sometimes next week.
Unfortunately, there were non-trivial API changes since version 2.39
that break most of the dependent packages. The first version with the
new API (2.90) was released more than a year ago, so I think the
upstreams had enough time to make necessary changes and we shouldn't
wait any longer.
Packages that currently use libgps.so.18:
qtgpsc-0:0.2.3-6.fc12
kdebase-workspace-0:4.4.2-5.fc14
vfrnav-0:0.4-1.fc13
gpsdrive-0:2.10-0.5.pre7.fc13
kdeedu-marble-libs-0:4.4.2-1.fc14
vifir-0:0.4-1.fc12
viking-0:0.9.9-1.fc12
Here is a gpsd srpm in case anyone wants to start preparing patches
http://fedorapeople.org/~mlichvar/tmp/gpsd-2.94-1.fc14.src.rpm
--
Miroslav Lichvar
13 years, 11 months
Re: [Test-Announce] Preupgrade Test Day - Thursday 2010-04-29
by Kevin Kofler
He Rui wrote:
> Test cases have been designed to cover common circumstances, including low
> /boot space status.
Why does the "too low /boot space to install" testcase (which is actually
the common case when upgrading from F12 or F11) still require manually
removing excess kernels, 6 months after this issue became initially known?
Preupgrade should do this automatically. After the upgrade, ALL the old
kernels will be removed anyway, so I don't see how it hurts to remove all
except the running one right away.
Kevin Kofler
13 years, 11 months
