[arch-general] [signoff] mdadm-3.1.4-1
Two fixes related to configs that aren't using udev: - Don't remove md devices which 'standard' names on --stop - Allow dev_open to work on read-only /dev And fixed regressions: - Allow --incremental to add spares to an array - Accept --no-degraded as a deprecated option rather than throwing an error - Return correct success status when --incrmental assembling a container which does not yet have enough devices. - Don't link mdadm with pthreads, only mdmon needs it. - Fix compiler warning due to bad use of snprintf - Fix spare migration Please signoff both arches greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] kde 4.5.1 ati/intel workarounds
I have both composite and raster enabled plasma desktop and apps running alongside very well here check it out. After just updating to 4.5.1 VSync was enabled again so I switched off. Best, -Martín Un buen antivirus, no debería dejar cargar Windows y sugerir instalar GNU/Linux xD - omar...@#parabola@freenode
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
2010-08-31 13:16, Dave Reisner:
On Tue, Aug 31, 2010 at 10:07:52AM +0200, Kurt J. Bosch wrote:
--snip--
I suggest:
From b202be97f8dc1c0c68aaea792d4457c674c673f3 Mon Sep 17 00:00:00 2001
From: Kurt J. Boschkjb-temp-2...@alpenjodel.de
Date: Tue, 31 Aug 2010 09:57:47 +0200
Subject: [PATCH 17/17] Correct behaviour of kill_everything()
---
functions | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/functions b/functions
index b9ba718..3ca7324 100644
--- a/functions
+++ b/functions
@@ -205,10 +205,9 @@ ck_status() {
kill_everything() {
# $1 = where we are being called from.
# This is used to determine which hooks to run.
-# Find daemons NOT in the DAEMONS array. Shut these down first
-for daemon in /var/run/daemons/*; do
-[[ -f $daemon ]] || continue
-daemon=${daemon##*/}
+# Find daemons NOT in the DAEMONS array.
+# Shut these down first in reverse order.
+for daemon in $( /bin/ls -t /var/run/daemons ); do
in_array $daemon ${daemo...@]} || stop_daemon $daemon
done
@@ -220,7 +219,7 @@ kill_everything() {
# Terminate all processes
stat_busy Sending SIGTERM To Processes
-run_hook $1_prekillall
+run_hook ${1}_prekillall
/sbin/killall5 -15 /dev/null
/bin/sleep 5
stat_done
@@ -230,7 +229,7 @@ kill_everything() {
/bin/sleep 1
stat_done
-run_hook $1_postkillall
+run_hook ${1}_postkillall
}
activate_vgs() {
--
1.7.0.3
Parsing the output of ls will never be better than using shell globbing
no matter how much simpler it might make the code appear to be. Not only
are you avoiding a fork, but the shell glob will properly handle any odd
characters thrown into the mix. You'll see breakage on something as
simple as a space in your suggestion. While I'm inclined to believe that
there will never be a space in the name of a daemon in Arch, if we're
going for pure Bash in this rewrite, let's use Bash instead of
mindlessly forking.
NAK. The patch just reverts breaking of the current behaviour which is
shutdown daemons in reverse order of start. AFAIK bash globbing is
unable to sort on timestamps, right? p
[arch-general] dovecot.conf kills update (conflicting file)
Guys, The dovecot update needs to be fixed. Currently, on upgrade you get: checking package integrity... (288/288) checking for file conflicts [#] 100% error: failed to commit transaction (conflicting files) dovecot: /etc/dovecot/dovecot.conf exists in filesystem Errors occurred, no packages were upgraded. which is a bit frustrating. I know we talked a little about fixing dovecot (and other packages that break if upgraded but not restarted) so I don't know if this is related (I thought the discussion/debate was whether to add a one-liner advising that a dovecot restart was required), but in any event, related or not, dovecot should update without failing due to the existing dovecot.conf Do I open a ticket or is this post enough? I have asked this question of whether to open a ticket on every bug or whether little items like this are preferred to be worked from the list w/o a ticket opened at least 3 times now and I have never received an answer (I apologize if I have missed it). I want to help Arch the best way I can. If you want bugs opened on everything, let me know -- I'm happy to open them. If you can work an issue from the list, then at least let me know I'll take it from here so I know things are not being missed. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] dovecot.conf kills update (conflicting file)
On 09/01/2010 07:44 AM, David C. Rankin wrote: Guys, The dovecot update needs to be fixed. Currently, on upgrade you get: checking package integrity... (288/288) checking for file conflicts [#] 100% error: failed to commit transaction (conflicting files) dovecot: /etc/dovecot/dovecot.conf exists in filesystem Errors occurred, no packages were upgraded. which is a bit frustrating. I know we talked a little about fixing dovecot (and other packages that break if upgraded but not restarted) so I don't know if this is related (I thought the discussion/debate was whether to add a one-liner advising that a dovecot restart was required), but in any event, related or not, dovecot should update without failing due to the existing dovecot.conf Do I open a ticket or is this post enough? I have asked this question of whether to open a ticket on every bug or whether little items like this are preferred to be worked from the list w/o a ticket opened at least 3 times now and I have never received an answer (I apologize if I have missed it). I want to help Arch the best way I can. If you want bugs opened on everything, let me know -- I'm happy to open them. If you can work an issue from the list, then at least let me know I'll take it from here so I know things are not being missed. Thanks. I forced the update and: warning: /etc/dovecot/dovecot.conf installed as /etc/dovecot/dovecot.conf.pacnew IMPORTANT DOVECOT 2.0 UPGRADE NOTICE see http://wiki2.dovecot.org/Upgrading/2.0 make sure, you convert the dovecot.conf file New optional dependencies for dovecot libmysqlclient: for MySQL back end postgresql-libs: for Postgres SQl back end ( 8/289) upgrading empathy [#] 100% To use Empathy you need to install at least one Telepathy connection manager. Great job on the notice :p -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] dovecot.conf kills update (conflicting file)
On Wed, 2010-09-01 at 07:44 -0500, David C. Rankin wrote: snip but in any event, related or not, dovecot should update without failing due to the existing dovecot.conf snip The dovecot.conf file was created by you previously, hence why the update is failing. The new dovecot package provides dovecot.conf (I think because upstream provides it). Pacman gives an error in situations like this, as it well should, since I doubt anybody wants their configs wiped out. As such I don't think this is even a bug.
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
On Wed, Sep 1, 2010 at 5:41 AM, Kurt J. Bosch
kjb-temp-2...@alpenjodel.de wrote:
2010-08-31 13:16, Dave Reisner:
On Tue, Aug 31, 2010 at 10:07:52AM +0200, Kurt J. Bosch wrote:
--snip--
I suggest:
From b202be97f8dc1c0c68aaea792d4457c674c673f3 Mon Sep 17 00:00:00 2001
From: Kurt J. Boschkjb-temp-2...@alpenjodel.de
Date: Tue, 31 Aug 2010 09:57:47 +0200
Subject: [PATCH 17/17] Correct behaviour of kill_everything()
---
functions | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/functions b/functions
index b9ba718..3ca7324 100644
--- a/functions
+++ b/functions
@@ -205,10 +205,9 @@ ck_status() {
kill_everything() {
# $1 = where we are being called from.
# This is used to determine which hooks to run.
- # Find daemons NOT in the DAEMONS array. Shut these down first
- for daemon in /var/run/daemons/*; do
- [[ -f $daemon ]] || continue
- daemon=${daemon##*/}
+ # Find daemons NOT in the DAEMONS array.
+ # Shut these down first in reverse order.
+ for daemon in $( /bin/ls -t /var/run/daemons ); do
in_array $daemon ${daemo...@]} || stop_daemon $daemon
done
@@ -220,7 +219,7 @@ kill_everything() {
# Terminate all processes
stat_busy Sending SIGTERM To Processes
- run_hook $1_prekillall
+ run_hook ${1}_prekillall
/sbin/killall5 -15 /dev/null
/bin/sleep 5
stat_done
@@ -230,7 +229,7 @@ kill_everything() {
/bin/sleep 1
stat_done
- run_hook $1_postkillall
+ run_hook ${1}_postkillall
}
activate_vgs() {
--
1.7.0.3
Parsing the output of ls will never be better than using shell globbing
no matter how much simpler it might make the code appear to be. Not only
are you avoiding a fork, but the shell glob will properly handle any odd
characters thrown into the mix. You'll see breakage on something as
simple as a space in your suggestion. While I'm inclined to believe that
there will never be a space in the name of a daemon in Arch, if we're
going for pure Bash in this rewrite, let's use Bash instead of
mindlessly forking.
NAK. The patch just reverts breaking of the current behaviour which is
shutdown daemons in reverse order of start. AFAIK bash globbing is unable to
sort on timestamps, right?
Bash globbing cannot handle it, but bash knows how to test file
timestamps, so we could code something up that handles killing the
daemons in reverse timestamp order if we had to. However, there is no
reason to think that the order is significant for daemons not in
$DAEMONS. If there are any dependencies that this code does not
handle gracefully, the offending daemons will be killed when we kill
-15 and then kill -9 the rest of the processes. If a daemon does not
handle SIGTERM gracefully because of dependency issues, it has other,
more significant problems.
Re: [arch-general] [PATCH 28/48] Use bash-style conditionals when setting up the hardware clock.
On Fri, Aug 20, 2010 at 2:12 AM, Kurt J. Bosch kjb-temp-2...@alpenjodel.de wrote: On 2010-08-19 23:12, Victor Lowther wrote: On Aug 19, 2010 10:08 AM, Kurt J. Boschkjb-temp-2...@alpenjodel.de wrote: On 2010-08-19 10:19, Jan de Groot wrote: On Thu, 2010-08-19 at 00:56 -0400, Dave Reisner wrote: Couldn't we avoid all this by just flipping a switch in the kernel? CONFIG_RTC_DRV_CMOS=y If it's compiled into the kernel, udev picks it up and creates the /dev nodes for us. Which still locks out the people who use a custom kernel with this driver compiled as module. IMHO the init scripts should work with both module and built-in. So why not let udev do the job? Patch below. I modified my initcpio to get rid of the devtmpfs. A ls -l /dev/rtc* added between the new /sbin/udevadm settle and the initial clock setting showed /dev/rtc0 and /dev/rtc - rtc0. So I think this should work. I did *not* move the sysinit_udevlaunched hook together with udev start to avoid insane creation times of dev nodes because this hook is used for some early udev triggering in fbsplash-extras (AUR). Patch against bashification-redux: From 22d410a2566964d58752d443a1312a6eb552660a Mon Sep 17 00:00:00 2001 From: Kurt J. Boschkjb-temp-2...@alpenjodel.de Date: Thu, 19 Aug 2010 16:46:23 +0200 Subject: [PATCH 17/17] Correct rtc dev nodes creation using udev --- rc.sysinit | 22 +++--- 1 files changed, 7 insertions(+), 15 deletions(-) diff --git a/rc.sysinit b/rc.sysinit index 4421def..2415967 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -46,6 +46,12 @@ else /bin/dmesg -n 3 fi +echo /proc/sys/kernel/hotplug + +stat_busy Starting UDev Daemon +/sbin/udevd --daemon +stat_done + HWCLOCK_PARAMS=--hctosys case $HARDWARECLOCK in UTC) HWCLOCK_PARAMS+= --utc;; @@ -56,15 +62,7 @@ esac if [[ $HWCLOCK_PARAMS ]]; then # enable rtc access /sbin/modprobe -q -a rtc-cmos rtc genrtc - # If devtmpfs is used, the required RTC device already exists now - # Otherwise, create whatever device is available - if ! [[ -c /dev/rtc || -c /dev/rtc0 ]]; then - for dev in /sys/class/rtc/rtc0/dev /sys/class/misc/rtc/dev; do - [[ -e $dev ]] || continue - IFS=: read -r major minor $dev - /bin/mknod /dev/rtc c $major $minor - done - fi + /sbin/udevadm settle # Do a clock set here for a few reasons: # 1. Make creation time on udev nodes sane (FS#8665) @@ -79,12 +77,6 @@ if [[ $HWCLOCK_PARAMS ]]; then fi fi -echo /proc/sys/kernel/hotplug - -stat_busy Starting UDev Daemon -/sbin/udevd --daemon -stat_done - run_hook sysinit_udevlaunched # Trigger udev uevents -- 1.7.2.1 I like this one the best. Sent from my Nexus One. Sorry for top posting. Corrected Hmm, the patch might break things with custom non modular kernels without devtmpfs though. No modules loading no uevents and no dev nodes. On the other hand reading the hwclock man page, I'm a bit uncertain whether that piece will ever use /dev/rtc0 without a symlink from /dev/rtc. Instead it might actually fall back to direct I/O with the current code and with the patched one too. Moreover I found a couple of interesting things: * The system clock is already set (by the kernel - in spite of CONFIG_RTC_HCTOSYS not set) even without doing anything. Weird, but with UTC hardware clock I even get correct mtimes in early user space. * man hwclock: --systz Reset the System Time based on the current timezone. ... This is an alternate option to --hctosys that does not read the hardware clock, and may be used in system startup scripts for recent 2.6 kernels where you know the System Time contains the Hardware Clock time. I switched my hardware clock to localtime, reverted my patch and modified rc.sysinit to use -systz instead of --hctosys for the first hwclock call and also disabled the entire rtc modprobe and mknod code. A date command inserted for testing spit out the correct time. From the util-linux-ng list: Indeed, we may be running hwclock --systz before /dev is mounted. Getting rid of the pre fsck hwclock --hctosys would also on the average save another half second of boot up time beside removing some ugly code. AFAIKS we can go one of three ways: * Use udev expecting CONFIG_RTC_DRV_CMOS=m or fall back to direct I/O * Use --systz, drop the ugly code and expect some help from the kernel * Use an even more ugly code creating the missing symlink: Corrected non udev patch against bashification-redux: From 4e5d6a763af8f45c63ad53aa99b82246f90c0b43 Mon Sep 17 00:00:00 2001 From: Kurt J. Bosch kjb-temp-2...@alpenjodel.de Date: Fri, 20 Aug 2010 09:04:46 +0200 Subject: [PATCH 17/17] Really correct rtc dev nodes creation --- rc.sysinit | 15 +-- 1 files changed, 9 insertions(+), 6 deletions(-) diff --git a/rc.sysinit b/rc.sysinit index 4421def..1ff37cc 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -58,12 +58,15 @@ if [[ $HWCLOCK_PARAMS ]]; then /sbin/modprobe -q -a
Re: [arch-general] dovecot.conf kills update (conflicting file)
On 09/01/2010 08:59 AM, Ng Oon-Ee wrote: On Wed, 2010-09-01 at 07:44 -0500, David C. Rankin wrote: snip but in any event, related or not, dovecot should update without failing due to the existing dovecot.conf snip The dovecot.conf file was created by you previously, hence why the update is failing. The new dovecot package provides dovecot.conf (I think because upstream provides it). Pacman gives an error in situations like this, as it well should, since I doubt anybody wants their configs wiped out. As such I don't think this is even a bug. ? Que? I thought that was what was supposed to be handled by .pacnew and .pacsav. Of course there will be a dovecot.conf. (dovecot won't work without it) Everybody knows that. Why should/would an Arch update not be able to handle that simple fact. You know more than I, but to me, it looks like a bug that Arch needs to be smart enough to fix. I propose that whoever maintains dovecot for Arch fix the install to install the new dovecot.conf and dovecot.conf.pacnew. That way we don't blow up a 288 package update just because the dovecot installer isn't smart enough to know that if dovecot is already installed - expect a dovecot.conf. Do you disagree with that? If so, why? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
[arch-general] kde 4.5.1-1 looks much better.
Guys, Even from a kde4 hater, kde 4.5.1-1 is looking much better than prior releases. Way to go Arch on the packaging. It is starting to add some of the efficiencies k3 had that k4 has lacked. Simple case-in-point, just rt-click to change the desktop wp and you now have a clean 3 column thumbnail setup that provides 300% more info than the old slow single column thumbnail list. Not earth-shattering, but it is good to see some of the really awkward dialogs getting reworked. Don't get me wrong, k4 still needs work, but I'm more than willing to tip my hat and recognize good progress when it has been made despite the 2.5 years of hell I've been though with that desktop. (as an aside - the 3D chessboard wallpaper is just killer) We shall see where it goes... -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
2010-09-01 13:03, Dave Reisner: The _current_ behavior doesn't define an order unless its in DAEMONS. I've reverted _your_ behavior, which I don't feel has proper justification. I referred to extras/initscripts which indeed does. Please read the code: http://projects.archlinux.org/initscripts.git/tree/rc.shutdown?id=2010.07-1 Suppose I start daemons foo, bar and baz (in that order) after Arch boots. Why then, should the shutdown order of these daemons change merely because I had to restart bar, which is independent of foo and baz? Because you know which is the right order and rc.shutdown just rolls back what you did. ^^
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
2010-09-01 17:29, Victor Lowther: Bash globbing cannot handle it, but bash knows how to test file timestamps, so we could code something up that handles killing the daemons in reverse timestamp order if we had to. However, there is no reason to think that the order is significant for daemons not in $DAEMONS. If there are any dependencies that this code does not handle gracefully, the offending daemons will be killed when we kill -15 and then kill -9 the rest of the processes. If a daemon does not handle SIGTERM gracefully because of dependency issues, it has other, more significant problems. I really don't know if this 'feature' is actually still wanted or needed, but I feel it should be dropped in a separate commit if ever. :)
Re: [arch-general] [signoff] mdadm-3.1.4-1
On Wed, Sep 1, 2010 at 1:44 AM, Tobias Powalowski t.p...@gmx.de wrote: Two fixes related to configs that aren't using udev: - Don't remove md devices which 'standard' names on --stop - Allow dev_open to work on read-only /dev And fixed regressions: - Allow --incremental to add spares to an array - Accept --no-degraded as a deprecated option rather than throwing an error - Return correct success status when --incrmental assembling a container which does not yet have enough devices. - Don't link mdadm with pthreads, only mdmon needs it. - Fix compiler warning due to bad use of snprintf - Fix spare migration Please signoff both arches Signoff x86_64
Re: [arch-general] kde 4.5.1-1 looks much better.
I noticed the wallpaper changer thing myself and think it's great to finally have that horrible dropdown list replaced with something decent. On the other hand, since the 4.5 update my Plasma-workspace process has crashed everytime I login to KDE via KDM. It respawns 15 seconds later and works fine but it always dies once right after login. Also, dolphin seems to be really slow and laggy. Rob On Wed, Sep 1, 2010 at 1:06 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: Guys, Even from a kde4 hater, kde 4.5.1-1 is looking much better than prior releases. Way to go Arch on the packaging. It is starting to add some of the efficiencies k3 had that k4 has lacked. Simple case-in-point, just rt-click to change the desktop wp and you now have a clean 3 column thumbnail setup that provides 300% more info than the old slow single column thumbnail list. Not earth-shattering, but it is good to see some of the really awkward dialogs getting reworked. Don't get me wrong, k4 still needs work, but I'm more than willing to tip my hat and recognize good progress when it has been made despite the 2.5 years of hell I've been though with that desktop. (as an aside - the 3D chessboard wallpaper is just killer) We shall see where it goes... -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] kde 4.5.1-1 looks much better.
On 2 September 2010 01:59, Robert Howard rjh0...@ecu.edu wrote: I noticed the wallpaper changer thing myself and think it's great to finally have that horrible dropdown list replaced with something decent. On the other hand, since the 4.5 update my Plasma-workspace process has crashed everytime I login to KDE via KDM. It respawns 15 seconds later and works fine but it always dies once right after login. Also, dolphin seems to be really slow and laggy. Dolphin has never failed to make me forget that I have more than 256MB of RAM, with or without thumbnailing. In contrast, Nautilus just works, let alone PCManFM or Thunar, even with thumbnailing on. KDE is fancy, but snappy it is not. -- GPG/PGP ID: B42DDCAD
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
On Wed, Sep 01, 2010 at 07:30:45PM +0200, Kurt J. Bosch wrote: 2010-09-01 13:03, Dave Reisner: The _current_ behavior doesn't define an order unless its in DAEMONS. I've reverted _your_ behavior, which I don't feel has proper justification. I referred to extras/initscripts which indeed does. Please read the code: http://projects.archlinux.org/initscripts.git/tree/rc.shutdown?id=2010.07-1 Indeed, I was mistaken. However, I still stand by the idea that trying to parse the output of /bin/ls is flawed from the ground up. ls is made for human parsing, not programatical parsing. Suppose I start daemons foo, bar and baz (in that order) after Arch boots. Why then, should the shutdown order of these daemons change merely because I had to restart bar, which is independent of foo and baz? Because you know which is the right order and rc.shutdown just rolls back what you did. ^^ No, rc.shutdown does _not_ know the right order. The current behavior is broken. Example: 1) start network 2) start rpcbind 3) start nfs-common 4) restart network network now shuts down first, rendering the OS unable to cleanly close any outstanding nfs shares. This commonly results in a long hang at shutdown and the possibility of truncated files. d
Re: [arch-general] kde 4.5.1-1 looks much better.
On 09/01/2010 12:59 PM, Robert Howard wrote: I noticed the wallpaper changer thing myself and think it's great to finally have that horrible dropdown list replaced with something decent. On the other hand, since the 4.5 update my Plasma-workspace process has crashed everytime I login to KDE via KDM. It respawns 15 seconds later and works fine but it always dies once right after login. Also, dolphin seems to be really slow and laggy. Rob Rob, Don't forget, for plasma restarts, there are only 3 commands required. If you find you need to restart plasma (or just to check for messages during restart), put the following in a little script called 'rsplasma' (or whatever you want to call it): #!/bin/bash kbuildsycoca4 # 'k'de 'build' 'sy'stem 'co'nfig 'ca'che kquitapp plasma-desktop /dev/null 21 # quit plasma kstart plasma-desktop /dev/null 21 # restart the darn thing and pray get rid of the '/dev/null 21' to see the bazillion lines of gibberish and errors. That may help narrow the issue. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] kde 4.5.1-1 looks much better.
On 09/01/2010 01:46 PM, Ray Rashif wrote: KDE is fancy, but snappy it is not. Funny, the windows side of the world found out that gigabyte desktops aren't that snappy either. Wonder if there is a common thread. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
2010-09-01 22:52, Dave Reisner: On Wed, Sep 01, 2010 at 07:30:45PM +0200, Kurt J. Bosch wrote: 2010-09-01 13:03, Dave Reisner: The _current_ behavior doesn't define an order unless its in DAEMONS. I've reverted _your_ behavior, which I don't feel has proper justification. I referred to extras/initscripts which indeed does. Please read the code: http://projects.archlinux.org/initscripts.git/tree/rc.shutdown?id=2010.07-1 Indeed, I was mistaken. However, I still stand by the idea that trying to parse the output of /bin/ls is flawed from the ground up. ls is made for human parsing, not programatical parsing. Suppose I start daemons foo, bar and baz (in that order) after Arch boots. Why then, should the shutdown order of these daemons change merely because I had to restart bar, which is independent of foo and baz? Because you know which is the right order and rc.shutdown just rolls back what you did. ^^ No, rc.shutdown does _not_ know the right order. The current behavior is broken. Example: 1) start network 2) start rpcbind 3) start nfs-common 4) restart network network now shuts down first, rendering the OS unable to cleanly close any outstanding nfs shares. This commonly results in a long hang at shutdown and the possibility of truncated files. That's exactly what I meant. _You_ should now what you're doing and rc.shutdown tries its best afterwards. There is no real daemons dependency handling in Arch (probably because of KISS) so we can't expect it does always the right thing, but at least without the restart it would do in your example and that's better than nothing (random order) isn't it? :)
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
On Thu, Sep 02, 2010 at 01:53:20AM +0200, Kurt J. Bosch wrote: 2010-09-01 22:52, Dave Reisner: On Wed, Sep 01, 2010 at 07:30:45PM +0200, Kurt J. Bosch wrote: 2010-09-01 13:03, Dave Reisner: The _current_ behavior doesn't define an order unless its in DAEMONS. I've reverted _your_ behavior, which I don't feel has proper justification. I referred to extras/initscripts which indeed does. Please read the code: http://projects.archlinux.org/initscripts.git/tree/rc.shutdown?id=2010.07-1 Indeed, I was mistaken. However, I still stand by the idea that trying to parse the output of /bin/ls is flawed from the ground up. ls is made for human parsing, not programatical parsing. Suppose I start daemons foo, bar and baz (in that order) after Arch boots. Why then, should the shutdown order of these daemons change merely because I had to restart bar, which is independent of foo and baz? Because you know which is the right order and rc.shutdown just rolls back what you did. ^^ No, rc.shutdown does _not_ know the right order. The current behavior is broken. Example: 1) start network 2) start rpcbind 3) start nfs-common 4) restart network network now shuts down first, rendering the OS unable to cleanly close any outstanding nfs shares. This commonly results in a long hang at shutdown and the possibility of truncated files. That's exactly what I meant. _You_ should now what you're doing and rc.shutdown tries its best afterwards. There is no real daemons dependency handling in Arch (probably because of KISS) so we can't expect it does always the right thing, but at least without the restart it would do in your example and that's better than nothing (random order) isn't it? :) Isn't the KISS solution just to add the thing to the DAEMONS array? We're clearly in disagreement, and this is getting a little circular. I'm going to bow out from this gracefully -- the devs can resolve this as they see fit.
Re: [arch-general] Hard disc clicks
On 09/01/10 00:25, Rafael Beraldo wrote: The thing is, 128 keeps the hard disc spinning down a lot. In fact, 254 is quite noiseless, but as from 253 the clicking sound returns. I read this bug page [3] but found nothing new. It is worth remembering that, sometimes, when I'm watching a movie or TV show with mplayer, it stops for less than I second, then I hear the disc spinning faster and the video continues. Some hard drives, such as yours, unfortunately don't have an intermediate setting. The hdparm -B values aren't in practice standardized. So, how did you guys set the power manager with hdparm in your laptops? Does anybody else have this problem? Since I move my netbook often, should I set it to 128 even if it spins down more than four times a minute? Depends whether you want your netbook to break (A) when you drop it or (B) after e.g. three years (or however long, depending on the frequency, more clicks = less lifetime). Some disks have sudden acceleration sensors that will also try to park the disk head when the disk feels itself being thrown across the room, making break-when-you-drop-it somewhat less likely. Since you have audible clicks, this might also weigh in favor of avoiding the clicks, if the noise bothers you or others... -Isaac
Re: [arch-general] kde 4.5.1-1 looks much better.
On Thursday 02 September 2010 04:53:24 David C. Rankin wrote: On 09/01/2010 01:46 PM, Ray Rashif wrote: KDE is fancy, but snappy it is not. Funny, the windows side of the world found out that gigabyte desktops aren't that snappy either. Wonder if there is a common thread. IMO KDE part of lost snappiness is due to addtional technical layers and latency between intra-daemon communication(nepomuk, strigi, akonadi and what not) rather than resource hog. It can be tuned down to bare minimum necessary. I have not seen the lag anytime but I have a 4GB ram machine. however konqueror and rekonq are far more snappier than anything else. firefox OTOH damn its slow to start. even soffice starts faster than it. I have no extensions installed. Another issue to consider is consistency of lag. on KDE side, its pretty much constant. On windows 7 machine at my work, its click and pray, despite of having a 2GB RAM machine.(1GB is taken by VM but lot is still free). Compared to KDE, that really unbearable. -- Regards Shridhar
Re: [arch-general] dovecot.conf kills update (conflicting file)
On 09/01/2010 06:08 PM, Ng Oon-Ee wrote: On Wed, 2010-09-01 at 11:58 -0500, David C. Rankin wrote: On 09/01/2010 08:59 AM, Ng Oon-Ee wrote: On Wed, 2010-09-01 at 07:44 -0500, David C. Rankin wrote: snip but in any event, related or not, dovecot should update without failing due to the existing dovecot.conf snip The dovecot.conf file was created by you previously, hence why the update is failing. The new dovecot package provides dovecot.conf (I think because upstream provides it). Pacman gives an error in situations like this, as it well should, since I doubt anybody wants their configs wiped out. As such I don't think this is even a bug. ? Que? I thought that was what was supposed to be handled by .pacnew and .pacsav. Of course there will be a dovecot.conf. (dovecot won't work without it) Everybody knows that. Why should/would an Arch update not be able to handle that simple fact. You know more than I, but to me, it looks like a bug that Arch needs to be smart enough to fix. I propose that whoever maintains dovecot for Arch fix the install to install the new dovecot.conf and dovecot.conf.pacnew. That way we don't blow up a 288 package update just because the dovecot installer isn't smart enough to know that if dovecot is already installed - expect a dovecot.conf. Do you disagree with that? If so, why? Files on the filesystem either belong to a package or they don't. dovecot.conf didn't, because the older dovecot packages (1.2-x) did not have the /etc/dovecot.conf file. You created that file yourself when you set dovecot up the first time. Now, the dovecot 2.0+ packages DO have that file. What else do you want pacman to do when the following is true:- 1. Package A did not use to own file B. 2. Package A now owns file B. 3. File B already exists on the filesystem. The file may not be a conf file. It may be a binary, a library etc. It may not even be intended for package A, but may belong, say, to package C. In any case, since YOU created it, you're responsible for deciding what you want to do with it. Pacman helps you manage your system, it doesn't (and shouldn't) try to make assumptions about stuff like this, because that's your job. You know your system better than anyone else (ideally). And your assertion about 'blowing up a 288 package update' is nonsense, by the time you reach this error the downloads are done (so they don't have to be repeated) and no files have actually yet been installed. Re-run pacman -Su after fixing the problem and everything just installs as it should have. Finally, there is no 'dovecot installer'. It is a package, a compressed collection of files. dovecot.install is mainly for post-install messages or perhaps some system configuration using common tools. Not to create configuration files from scratch (that's your job). OK, I'm buying it. What you are telling me is that for 1X there was NO dovecot.conf (IIRC it was something like dovecot.conf.example because I compared something to my suse dovecot.conf when I moved to Arch)AND... you are saying since 1X didn't have one, the fact that 2.0 does somehow causes the 1.x-2.0 update to evade (or fall outside of) the way the .pacnew logic works because the 2.0 install doesn't know about 1.x having a dovecot.conf?? That just seems wonky. So for httpd, it has a httpd.conf from the first version, so it doesn't complain when apache is updated or you get a .pacnew. OK, then, this 1.2-2.0 transition should be the only dovecot update that craters the update do to the existence of the dovecot.conf file. So when I updae to 2.1, there should be no update killing complaint about the dovecot.conf. Right? Just seems weird that any package with a mandatory config would puke when it finds the mandatory config from a prior version actually there. So far this dovecot update, *every* Archer that updates will have the update fail do to this problem, but the next update to 2.0-X should be fine, right? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
[arch-general] 2.6.35.4-1 still hangs waiting on udev with usbhid errors
Guys, There are still usbhid-ups problem on boot that hang the boot and don't configure the usbhid-ups driver. This is a flakey issue. I have booted twice, hung the first time (errors below), rebooted and got by the udev/usbhid load in boot and upsmonitoring worked fine. The problem is, there is no way I can remotely administer this box with a 50% chance of it hanging on boot. Any ideas? Here is the error log from everything.log Aug 30 20:30:28 archangel kernel: eth0: no IPv6 routers present Aug 30 20:30:30 archangel kdm_greet[2283]: Cannot load /usr/share/apps/kdm/faces/.default.face: No such file or directory Aug 30 20:31:03 archangel upsd[2295]: listening on 192.168.6.14 port 3493 Aug 30 20:31:03 archangel upsd[2295]: listening on 127.0.0.1 port 3493 Aug 30 20:31:03 archangel upsd[2295]: Can't connect to UPS [archangel_ups] (usbhid-ups-archangel_ups): No such f ile or directory Aug 30 20:31:03 archangel upsd[2296]: Startup successful Aug 30 20:31:03 archangel upsmon[2298]: Startup successful Aug 30 20:31:03 archangel upsmon[2300]: Login on UPS [archangel_...@localhost] failed - got [ERR ACCESS-DENIED] Aug 30 20:31:03 archangel upsmon[2300]: Login on UPS [nirvana_...@nirvana.3111skyline.com] failed - got [ERR ACC ESS-DENIED] Aug 30 20:31:06 archangel kernel: INFO: task modprobe:1579 blocked for more than 120 seconds. Aug 30 20:31:06 archangel kernel: echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Aug 30 20:31:06 archangel kernel: modprobe D 0 1579 1576 0x Aug 30 20:31:06 archangel kernel: 88022616da28 0082 8167eb00 8802 Aug 30 20:31:06 archangel kernel: 00014f40 00014f40 88022616dfd8 88022616dfd8 Aug 30 20:31:06 archangel kernel: 88022616dfd8 8802269c1bc0 88022616dfd8 00014f40 Aug 30 20:31:06 archangel kernel: Call Trace: Aug 30 20:31:06 archangel kernel: [a0202ba5] usb_kill_urb+0x85/0xc0 [usbcore] Aug 30 20:31:06 archangel kernel: [810718d0] ? autoremove_wake_function+0x0/0x40 Aug 30 20:31:06 archangel kernel: [a02e0831] usbhid_init_reports+0xb1/0x120 [usbhid] Aug 30 20:31:06 archangel kernel: [a02e0d53] usbhid_start+0x4b3/0x5a0 [usbhid] Aug 30 20:31:06 archangel kernel: [a02ca6d8] hid_device_probe+0x98/0xe0 [hid] Aug 30 20:31:06 archangel kernel: [812877ea] ? driver_sysfs_add+0x5a/0x90 Aug 30 20:31:06 archangel kernel: [81287ac6] driver_probe_device+0x96/0x1c0 Aug 30 20:31:06 archangel kernel: [81287c90] ? __device_attach+0x0/0x60 Aug 30 20:31:06 archangel kernel: [81287cdb] __device_attach+0x4b/0x60 Aug 30 20:31:06 archangel kernel: [812866a4] bus_for_each_drv+0x64/0x90 Aug 30 20:31:06 archangel kernel: [8128795f] device_attach+0x8f/0xb0 Aug 30 20:31:06 archangel kernel: [81287115] bus_probe_device+0x25/0x40 Aug 30 20:31:06 archangel kernel: [81284e5f] device_add+0x4ff/0x5e0 Aug 30 20:31:06 archangel kernel: [a02ca0a7] hid_add_device+0x87/0x1b0 [hid] Aug 30 20:31:06 archangel kernel: [a02de4b9] usbhid_probe+0x329/0x500 [usbhid] Aug 30 20:31:06 archangel kernel: [a0207a2b] usb_probe_interface+0xfb/0x1f0 [usbcore] Aug 30 20:31:06 archangel kernel: [81287ac6] driver_probe_device+0x96/0x1c0 Aug 30 20:31:06 archangel kernel: [81287c8b] __driver_attach+0x9b/0xa0 Aug 30 20:31:06 archangel kernel: [81287bf0] ? __driver_attach+0x0/0xa0 Aug 30 20:31:06 archangel kernel: [812869fe] bus_for_each_dev+0x5e/0x90 Aug 30 20:31:06 archangel kernel: [81287789] driver_attach+0x19/0x20 Aug 30 20:31:06 archangel kernel: [81287297] bus_add_driver+0xc7/0x2e0 Aug 30 20:31:06 archangel kernel: [81287f01] driver_register+0x71/0x140 Aug 30 20:31:06 archangel kernel: [a02066f8] usb_register_driver+0xb8/0x170 [usbcore] Aug 30 20:31:06 archangel kernel: [a0299000] ? hid_init+0x0/0xd1 [usbhid] Aug 30 20:31:06 archangel kernel: [a0299093] hid_init+0x93/0xd1 [usbhid] Aug 30 20:31:06 archangel kernel: [81002149] do_one_initcall+0x39/0x1a0 Aug 30 20:31:06 archangel kernel: [8108cefb] sys_init_module+0xbb/0x200 Aug 30 20:31:06 archangel kernel: [81009e82] system_call_fastpath+0x16/0x1b Aug 30 20:31:08 archangel upsmon[2300]: Poll UPS [archangel_...@localhost] failed - Driver not connected Aug 30 20:31:08 archangel upsmon[2300]: Communications with UPS archangel_...@localhost lost Aug 30 20:31:08 archangel wall[2302]: wall: user nut broadcasted 1 lines (54 chars) Aug 30 20:31:13 archangel upsmon[2300]: Poll UPS [archangel_...@localhost] failed - Driver not connected Aug 30 20:31:13 archangel upsmon[2300]: UPS archangel_...@localhost is unavailable Aug 30 20:31:13 archangel wall[2305]: wall: user nut broadcasted 1 lines (44 chars) Aug 30 20:31:18 archangel upsmon[2300]: Poll UPS [archangel_...@localhost] failed -
Re: [arch-general] Hard disc clicks
On 09/01/2010 10:22 PM, Isaac Dupree wrote: On 09/01/10 00:25, Rafael Beraldo wrote: The thing is, 128 keeps the hard disc spinning down a lot. In fact, 254 is quite noiseless, but as from 253 the clicking sound returns. I read this bug page [3] but found nothing new. It is worth remembering that, sometimes, when I'm watching a movie or TV show with mplayer, it stops for less than I second, then I hear the disc spinning faster and the video continues. Some hard drives, such as yours, unfortunately don't have an intermediate setting. The hdparm -B values aren't in practice standardized. So, how did you guys set the power manager with hdparm in your laptops? Does anybody else have this problem? Since I move my netbook often, should I set it to 128 even if it spins down more than four times a minute? Depends whether you want your netbook to break (A) when you drop it or (B) after e.g. three years (or however long, depending on the frequency, more clicks = less lifetime). Some disks have sudden acceleration sensors that will also try to park the disk head when the disk feels itself being thrown across the room, making break-when-you-drop-it somewhat less likely. Since you have audible clicks, this might also weigh in favor of avoiding the clicks, if the noise bothers you or others... -Isaac In my experience, hard disc clicks are never good. I've run drives where the read/write head would click on occasion and continue to work, but you always know in the back of your mind that there is a issue with the drive controller sending the read/write head on excursions across the disc to either figure out where it is or to try and cage itself. Neither should occur normally (OK some drives do cage the r/w head normally on spindown) I have run drives like that for 1 year+ before the clicking finally becomes the deathnail of the drive. Backup early and often... -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] dovecot.conf kills update (conflicting file)
On Wed, 2010-09-01 at 23:35 -0500, David C. Rankin wrote: On 09/01/2010 06:08 PM, Ng Oon-Ee wrote: snip OK, I'm buying it. What you are telling me is that for 1X there was NO dovecot.conf (IIRC it was something like dovecot.conf.example because I compared something to my suse dovecot.conf when I moved to Arch)AND... you are saying since 1X didn't have one, the fact that 2.0 does somehow causes the 1.x-2.0 update to evade (or fall outside of) the way the .pacnew logic works because the 2.0 install doesn't know about 1.x having a dovecot.conf?? Yes, that's what I'm saying. That just seems wonky. So for httpd, it has a httpd.conf from the first version, so it doesn't complain when apache is updated or you get a .pacnew. OK, then, this 1.2-2.0 transition should be the only dovecot update that craters the update do to the existence of the dovecot.conf file. So when I updae to 2.1, there should be no update killing complaint about the dovecot.conf. Right? Right. Just seems weird that any package with a mandatory config would puke when it finds the mandatory config from a prior version actually there. So far this dovecot update, *every* Archer that updates will have the update fail do to this problem, but the next update to 2.0-X should be fine, right? You seem to be quite uninformed about what packaging actually is. Various statements you make about 'dovecot installer' and 'update killing complaint' indicate this. Packaging is separate from the application, and the job done by the package management system is actually very simple at its core (keep track of files belonging to a package). Basically, 'installation' means something very different on a Linux system than on a Windows system (which is where your comments seem rooted). If you would take some time to try and understand the various things pacman does, you'd save yourself and others a lot more time on the various issues you bring to this list. Cheers, Ng Oon-Ee
