Re: [arch-general] dovecot.conf kills update (conflicting file)
On Thu, 2010-09-02 at 23:02 -0500, David C. Rankin wrote: > On 09/01/2010 06:08 PM, Ng Oon-Ee wrote: > > 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. > > OK, > > Now let's turn this conversation around and see if we can't make Arch > better. I > agree with all you said, and yes, I understand the 'packaging' and installer > separation and what pacman does/doesn't do. What I want to explore is what > additional effort would it take to identify and make the packaging process > (for > core server apps especially - mail/apache/etc.) more robust so that pacman > can > be made 'aware' of mandatory config files that should be expected? That's the thing, pacman IS aware of it (post dovecot 2). What you're requesting, if I read correctly, is some sort of 'intelligent input' that 'package A tends to need config file B, and font C, D, E, even though they're not in the package at this point they may be in the future'. > > The way I look at it is if Arch is going to keep moving forward, > kicking ass > and gaining market share the way it has in the past, then these are some of > the > things I notice that, if fixed, will add some of the required 'polish' to > Arch > to allow it to continue do so. Nothing more, nothing less. I very much doubt 'moving forward, kicking ass, and gaining market share' is on the to-do list of any of the devs. There's a whole different mindset here, chasing a larger user count is not the purpose. That being said, it would probably be possible to implement something like what you seem to be suggesting. I doubt it ever will though, because this IS very much a corner case.
Re: [arch-general] 2.6.35.4-1 still hangs waiting on udev with usbhid errors
On Thu, Sep 2, 2010 at 23:33, David C. Rankin wrote: > On 09/02/2010 11:23 PM, David C. Rankin wrote: >> >> I had opened a bug on it, but I guess somebody closed it because I can't >> find >> the bug now. > > Correction - I didn't open a bug on this one, I was thinking about the > dmraid fail to boot bug where I provided all the hardware info: > > http://bugs.archlinux.org/task/20499 > > Let me know if this needs to be opened as a bug. > > -- > 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 > David: That was my only suggestion. I stopped having usb problems once I listed all my usb modules in rc.conf, so I'm out of ideas. Myra PS Dallas is on I45 and East of I35. I won't even go East of the Brazos anymore. BWood is it. -- Life's fun when your sick and psychotic!
[arch-general] Remove duplicate packages from /var/cache/pacman/pkg script updated
In case anyone uses it, I updated my fduppkg script that scans /var/cache/pacman/pkg and moves duplicate packages to a separate directory so you can either keep the current + last package sets or just delete the dups. This update just cleans up the output and adds an -s | --silent option that suppresses all screen output and simply writes to the log file. Additionally the screen output has been cleaned up so it looks like this now: [14:18 alchemy:/home/david] # fduparch fduppkg /var/cache/pacman/pkg -d /home/backup/pkg-old -l /home/backup/pkgdups.log Total packages to screen: 2858 Removing duplicates from: /var/cache/pacman/pkg Duplicates directory: /home/backup/pkg-old Log file location: /home/backup/pkgdups.log Verbose mode set: [use -q to stop pkg output | -s to stop all output] pkg [ 434] feh dup => feh-1.8-1-x86_64.pkg.tar.xz pkg [ 727] gstreamer0 dup => gstreamer0.10-ugly-0.10.15-4-x86_64.pkg.tar.xz pkg [ 785] gtranslator dup => gtranslator-1.9.7-1-x86_64.pkg.tar.gz pkg [1446] kernel26-docs dup => kernel26-docs-2.6.35.3-1-x86_64.pkg.tar.xz pkg [1869] lpsolve dup => lpsolve-5.5.0.15-1-x86_64.pkg.tar.gz pkg [1895] madwifi dup => madwifi-0.9.4.4119-2-x86_64.pkg.tar.xz pkg [2043] obexd-clientdup => obexd-client-0.29-3-x86_64.pkg.tar.xz pkg [2070] openssh dup => openssh-5.5p1-1-x86_64.pkg.tar.xz pkg [2263] pulseaudio dup => pulseaudio-0.9.21-8-x86_64.pkg.tar.xz pkg [2399] rubydup => ruby-1.9.1_p429-1-x86_64.pkg.tar.xz pkg [2537] timidity++ dup => timidity++-2.13.2-9-x86_64.pkg.tar.xz 11 duplicates moved to /home/backup/pkg-old I've set the package name field width to 26 as a compromise to handle most package names. (You wouldn't have any screen left if it was wide enough for all the screwy kde4 50+ char package names). If the output above wraps -- you get the drift. In verbose mode (default) you get a summary showing the total number of packages to be screened, being moved from /var/cache/pacman/pkg to the dupdir you specify and the files moved are logged in the logfile you specify. The package listing just shows the array index for the current package and any dups found are shown on the right. I find it handy, YMMV. The way I use it is to set up a 'wrapper script' to call fduppkg twice. Once to move dups from /var/cache/pacman/pkg => /home/backup/pkg-old Then again to move dups from /home/backup/pkg-old => /home/backup/pkg-older That way I have the current set in /var/cache/pacman/pkg and a clean last installed set in /home/backup/pkg-old. Plus moving to /home/backup will offload the storage from / to /home partitions on most installs. The main fduppkg scrip is here: http://www.3111skyline.com/dl/Archlinux/scripts/fduppkg The wrapper script I use to call fduppkg is here: http://www.3111skyline.com/dl/Archlinux/scripts/fduparch.sh I just link the scripts to /usr/local/bin as follows and then make sure /usr/local/bin is in your path: lrwxrwxrwx 1 root root 32 Apr 18 19:17 fduparch -> /home/david/scr/arch/fduparch.sh lrwxrwxrwx 1 root root 28 Apr 18 19:18 fduppkg -> /home/david/scr/arch/fduppkg Then once you have edited fduparch.sh and set the directories and options the way you like it, just call fduparch as root or 'sudo fduparch' and all dups will be moved to the directory you specify. (NOTE: this script uses the package DATE to determine which is the newest package, so if you have somehow reset all the ctime or mtime info on your files by block copying them without preserving the file attributes, it won't work) (Yes I know I have left comments and commented out stuff in the scripts, they are still works in progress :-) -- 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] 2.6.35.4-1 still hangs waiting on udev with usbhid errors
On 09/02/2010 11:23 PM, David C. Rankin wrote: I had opened a bug on it, but I guess somebody closed it because I can't find the bug now. Correction - I didn't open a bug on this one, I was thinking about the dmraid fail to boot bug where I provided all the hardware info: http://bugs.archlinux.org/task/20499 Let me know if this needs to be opened as a bug. -- 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] 2.6.35.4-1 still hangs waiting on udev with usbhid errors
On 09/02/2010 04:34 AM, Myra Nelson wrote: David: Stupid question 1, is the usbhid-ups a kernel module (I assume it is, just making sure)? Stupid question 2, do you have the module listed in the modules section of your rc.conf? I've found it much easier to list the modules I need in the rc.conf file and the system "seems" to boot a little faster. I listed all the modules from "lsmod". Myra off topic warning PS. If you would move West of I35 you would have less trouble. The devil made me say that. ROTFLMAO I'm from Dallas originally -- right on top of I35 - so I don't really think that will help :p There are no stupid questions, I have already asked them all! Seriously, yes usbhid-ups is a kernel module used by community/network-ups-tools to enable communications with your UPS. I'm currently running network-ups-tools-2.4.1-1. No - it isn't listed in my rc.conf: MODULES=(dm_mod dm_mirror sata_nv nvidia) So this is one of those that is UDEV activated if the ups is present. I guess if it isn't plugged in on boot, the usbhid-ups driver would never be called. Now this flaky behavior is only on 1 of two boxes I have so I suspect there is some type of bug (a kernel bug maybe) related to the nvidia chipset on this box. I had opened a bug on it, but I guess somebody closed it because I can't find the bug now. I provided all the chipset and hardware info there. Basically, the box is a: MSI K9N2 SLI Platinum Mobo Manufacturer: MSI Product Name: MS-7374 Processor: Phenom Quad Core 9850 Ram: 8G The usb and pci buses looks like this: [23:19 archangel:/home/david/cnf/egw] # lsusb Bus 004 Device 002: ID 045e:0095 Microsoft Corp. IntelliMouse Explorer 4.0 (IntelliPoint) Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub [23:16 archangel:/home/david/cnf/egw] # lspci 00:00.0 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a2) 00:01.0 ISA bridge: nVidia Corporation MCP78S [GeForce 8200] LPC Bridge (rev a2) 00:01.1 SMBus: nVidia Corporation MCP78S [GeForce 8200] SMBus (rev a1) 00:01.2 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a1) 00:01.3 Co-processor: nVidia Corporation MCP78S [GeForce 8200] Co-Processor (rev a2) 00:01.4 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a1) 00:02.0 USB Controller: nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1) 00:02.1 USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1) 00:04.0 USB Controller: nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1) 00:04.1 USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1) 00:06.0 IDE interface: nVidia Corporation MCP78S [GeForce 8200] IDE (rev a1) 00:07.0 Audio device: nVidia Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio (rev a1) 00:08.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1) 00:09.0 RAID bus controller: nVidia Corporation MCP78S [GeForce 8200] SATA Controller (RAID mode) (rev a2) 00:0a.0 Ethernet controller: nVidia Corporation MCP77 Ethernet (rev a2) 00:10.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1) 00:12.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1) 00:13.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1) 00:14.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control 00:18.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control 01:06.0 Serial controller: 3Com Corp, Modem Division 56K FaxModem Model 5610 (rev 01) 01:09.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) 02:00.0 VGA compatible controller: nVidia Corporation G92 [GeForce 8800 GT] (rev a2) 04:00.0 SATA controller: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller (rev 03) 04:00.1 IDE interface: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller (rev 03) Up until this latest string of usbhid problems, I have used this same UPS and setup for a couple of years with both SuSE and Arch and I have never experienced problem like this until the last ke
Re: [arch-general] dovecot.conf kills update (conflicting file)
On 09/01/2010 06:08 PM, Ng Oon-Ee wrote: 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. OK, Now let's turn this conversation around and see if we can't make Arch better. I agree with all you said, and yes, I understand the 'packaging' and installer separation and what pacman does/doesn't do. What I want to explore is what additional effort would it take to identify and make the packaging process (for core server apps especially - mail/apache/etc.) more robust so that pacman can be made 'aware' of mandatory config files that should be expected? Additionally, there needs to be a 'non-critical' check that is employed for the times when an already installed font causes the install to fail. This isn't a giant problem, but it is an annoyance. Over the past 1.5 years on 8-10 Arch boxes, I have run into a dozen issues like this. Some for something as simple as a specific font already being installed which causes the install to stop as mentioned above. I'm not knocking Arch, I'm just trying to explore how much work it would take to make pacman just a little smarter so it avoids some of these things. That is what I DON'T know. The way I look at it is if Arch is going to keep moving forward, kicking ass and gaining market share the way it has in the past, then these are some of the things I notice that, if fixed, will add some of the required 'polish' to Arch to allow it to continue do so. Nothing more, nothing less. If it is too much work from a cost/benefit standpoint, then just throw this in the "Arch Ideas" files for later or hit 'del'. -- 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.
Robert Howard wrote: > Perhaps I misstated my point. My system is pretty snappy when it's working > right (it should be as I've got 8GB RAM and 8 CPU cores) but since the > last update Dolphin literally stop working for short periods when you > interact with files (mouse over, click, right click). It's a total freeze > of the application and it can take anywhere from 15-20 seconds to respond > again. > That's a known dbus issue, it should be fixed in dbus-core from [testing]
Re: [arch-general] kde 4.5.1-1 looks much better.
Perhaps I misstated my point. My system is pretty snappy when it's working right (it should be as I've got 8GB RAM and 8 CPU cores) but since the last update Dolphin literally stop working for short periods when you interact with files (mouse over, click, right click). It's a total freeze of the application and it can take anywhere from 15-20 seconds to respond again. On Thu, Sep 2, 2010 at 12:23 AM, Shridhar Daithankar < ghodech...@ghodechhap.net> wrote: > 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 >
[arch-general] Multilib Repo Thanks
Hello altogether and especially to the people contributing to the multilib repo. Having this repo is so damn great! Really good work. If I would have been asked to send in a wishlist, of my most desired features, a month ago such a repo would have been on place one!!! Thank you guys Benedikt
[arch-general] KDE Thumbnail bug?
Recently after upgrading KDE on my arch64 installation, neither dolphin or konqueror don't show thumbnails for images. They just show the thumbnail as a question mark (like that for an unknown file). I deleted the configuration, etc. but still no solution. What can be the problem? A bug or something to do with configuration / arch? -- Regards, Nilesh Govindarajan Facebook: http://www.facebook.com/nilesh.gr Twitter: http://twitter.com/nileshgr Website: http://www.itech7.com VPS Hosting: http://www.itech7.com/a/vps
Re: [arch-general] Hard disc clicks
On Thu, Sep 2, 2010 at 15:54, Rafael Beraldo wrote: > I added hdparm -B 254 /dev/sda to /etc/rc.local, but I don't know if it is a > good solution either. Anyway, as Isaac Dupree said, unfortunatelly there is > no intermediate setting, then it is best not to have anoying and (I think) > dangerous clicks. It is dangerous. I got a new HDD killed in 3 weeks, the clicks happened more and more often and after a while, the driver started to produce read errors. I thought that the drive was faulty and got it replaced in warranty. After the replacement drive also produced the clicks I found out about the whole hdparm thing, set the value to 254 and the drive is working fine for almost 3 years now. -- ijanos
Re: [arch-general] Hard disc clicks
On 2 September 2010 10:46, Nicolas Bevilacqua wrote: > > I have the same netbook and the same problem. I resolved by changing a few > lines in the file /etc/hdparm.conf. > > Adding at the end the lines: > > # apm setting when on battery > apm_battery = 254 > # -S standby (spindown) timeout for the drive > spindown_time = 0 > > But, I don't now if this solution is the better. > > PD: Sorry, my english is not very good :b. > Nicolas, I added hdparm -B 254 /dev/sda to /etc/rc.local, but I don't know if it is a good solution either. Anyway, as Isaac Dupree said, unfortunatelly there is no intermediate setting, then it is best not to have anoying and (I think) dangerous clicks. -- Rafael Beraldo http://cabaladada.org
Re: [arch-general] Hard disc clicks
El 02/09/2010 01:58 a.m., David C. Rankin escribió: 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... I have the same netbook and the same problem. I resolved by changing a few lines in the file /etc/hdparm.conf. Adding at the end the lines: # apm setting when on battery apm_battery = 254 # -S standby (spindown) timeout for the drive spindown_time = 0 But, I don't now if this solution is the better. PD: Sorry, my english is not very good :b.
Re: [arch-general] dovecot.conf kills update (conflicting file)
On Thu, 2010-09-02 at 05:39 -0400, Baho Utot wrote: > On 09/01/2010 07: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: > >>> > but in any event, related or not, > dovecot should update without failing due to the existing dovecot.conf > >>> > >>> > >>> 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). > > > > The proper thing to do is to rename /etc/dovecot.conf to > dovecot.conf.orginal, do the update and then merge/restore the > dovecot.conf.orginal to/into dovecot.conf. > > Then everyone is happy. > Actually, the proper thing to do is stated in the post-install message. The behaviour you're talking about is not done by pacman, because with dovecot 1.2 dovecot.conf was not part of the dovecot package, as already mentioned.
Re: [arch-general] dovecot.conf kills update (conflicting file)
On 09/01/2010 07: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: but in any event, related or not, dovecot should update without failing due to the existing dovecot.conf 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). The proper thing to do is to rename /etc/dovecot.conf to dovecot.conf.orginal, do the update and then merge/restore the dovecot.conf.orginal to/into dovecot.conf. Then everyone is happy.
Re: [arch-general] 2.6.35.4-1 still hangs waiting on udev with usbhid errors
On Thu, Sep 2, 2010 at 03:08, Jude DaShiell wrote: > I've tried sever reinstalls of talking archlinux after the August 19, 2010 > kernel update and though the Linux installs, it never comes up talking. The > sound card device of course is controled by udev so this explains the reason > for the failures. I'm doing internet installs since that's how that disk > was set up.On Wed, 1 Sep 2010, David C. Rankin wrote: > >> 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: [] >> usb_kill_urb+0x85/0xc0 [usbcore] >> Aug 30 20:31:06 archangel kernel: [] ? >> autoremove_wake_function+0x0/0x40 >> Aug 30 20:31:06 archangel kernel: [] >> usbhid_init_reports+0xb1/0x120 [usbhid] >> Aug 30 20:31:06 archangel kernel: [] >> usbhid_start+0x4b3/0x5a0 [usbhid] >> Aug 30 20:31:06 archangel kernel: [] >> hid_device_probe+0x98/0xe0 [hid] >> Aug 30 20:31:06 archangel kernel: [] ? >> driver_sysfs_add+0x5a/0x90 >> Aug 30 20:31:06 archangel kernel: [] >> driver_probe_device+0x96/0x1c0 >> Aug 30 20:31:06 archangel kernel: [] ? >> __device_attach+0x0/0x60 >> Aug 30 20:31:06 archangel kernel: [] >> __device_attach+0x4b/0x60 >> Aug 30 20:31:06 archangel kernel: [] >> bus_for_each_drv+0x64/0x90 >> Aug 30 20:31:06 archangel kernel: [] >> device_attach+0x8f/0xb0 >> Aug 30 20:31:06 archangel kernel: [] >> bus_probe_device+0x25/0x40 >> Aug 30 20:31:06 archangel kernel: [] >> device_add+0x4ff/0x5e0 >> Aug 30 20:31:06 archangel kernel: [] >> hid_add_device+0x87/0x1b0 [hid] >> Aug 30 20:31:06 archangel kernel: [] >> usbhid_probe+0x329/0x500 [usbhid] >> Aug 30 20:31:06 archangel kernel: [] >> usb_probe_interface+0xfb/0x1f0 [usbcore] >> Aug 30 20:31:06 archangel kernel: [] >> driver_probe_device+0x96/0x1c0 >> Aug 30 20:31:06 archangel kernel: [] >> __driver_attach+0x9b/0xa0 >> Aug 30 20:31:06 archangel kernel: [] ? >> __driver_attach+0x0/0xa0 >> Aug 30 20:31:06 archangel kernel: [] >> bus_for_each_dev+0x5e/0x90 >> Aug 30 20:31:06 archangel kernel: [] >> driver_attach+0x19/0x20 >> Aug 30 20:31:06 archangel kernel: [] >> bus_add_driver+0xc7/0x2e0 >> Aug 30 20:31:06 archangel kernel: [] >> driver_register+0x71/0x140 >> Aug 30 20:31:06 archangel kernel: [] >> usb_register_driver+0xb8/0x170 [usbcore] >> Aug 30 20:31:06 archangel kernel: [] ? hid_init+0x0/0xd1 >> [usbhid] >> Aug 30 20:31:06 archangel kernel: [] hid_init+0x93/0xd1 >> [usbhid] >> Aug 30 20:31:06 archangel kernel: [] >> do_one_initcall+0x39/0x1a0 >> Aug 30 20:31:06 archangel kernel: [] >> sys_init_module+0xbb/0x200 >> Aug 30 20:31:06 archangel kernel: [] >> 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 archange
Re: [arch-general] 2.6.35.4-1 still hangs waiting on udev with usbhid errors
I've tried sever reinstalls of talking archlinux after the August 19, 2010 kernel update and though the Linux installs, it never comes up talking. The sound card device of course is controled by udev so this explains the reason for the failures. I'm doing internet installs since that's how that disk was set up.On Wed, 1 Sep 2010, David C. Rankin wrote: 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: [] usb_kill_urb+0x85/0xc0 [usbcore] Aug 30 20:31:06 archangel kernel: [] ? autoremove_wake_function+0x0/0x40 Aug 30 20:31:06 archangel kernel: [] usbhid_init_reports+0xb1/0x120 [usbhid] Aug 30 20:31:06 archangel kernel: [] usbhid_start+0x4b3/0x5a0 [usbhid] Aug 30 20:31:06 archangel kernel: [] hid_device_probe+0x98/0xe0 [hid] Aug 30 20:31:06 archangel kernel: [] ? driver_sysfs_add+0x5a/0x90 Aug 30 20:31:06 archangel kernel: [] driver_probe_device+0x96/0x1c0 Aug 30 20:31:06 archangel kernel: [] ? __device_attach+0x0/0x60 Aug 30 20:31:06 archangel kernel: [] __device_attach+0x4b/0x60 Aug 30 20:31:06 archangel kernel: [] bus_for_each_drv+0x64/0x90 Aug 30 20:31:06 archangel kernel: [] device_attach+0x8f/0xb0 Aug 30 20:31:06 archangel kernel: [] bus_probe_device+0x25/0x40 Aug 30 20:31:06 archangel kernel: [] device_add+0x4ff/0x5e0 Aug 30 20:31:06 archangel kernel: [] hid_add_device+0x87/0x1b0 [hid] Aug 30 20:31:06 archangel kernel: [] usbhid_probe+0x329/0x500 [usbhid] Aug 30 20:31:06 archangel kernel: [] usb_probe_interface+0xfb/0x1f0 [usbcore] Aug 30 20:31:06 archangel kernel: [] driver_probe_device+0x96/0x1c0 Aug 30 20:31:06 archangel kernel: [] __driver_attach+0x9b/0xa0 Aug 30 20:31:06 archangel kernel: [] ? __driver_attach+0x0/0xa0 Aug 30 20:31:06 archangel kernel: [] bus_for_each_dev+0x5e/0x90 Aug 30 20:31:06 archangel kernel: [] driver_attach+0x19/0x20 Aug 30 20:31:06 archangel kernel: [] bus_add_driver+0xc7/0x2e0 Aug 30 20:31:06 archangel kernel: [] driver_register+0x71/0x140 Aug 30 20:31:06 archangel kernel: [] usb_register_driver+0xb8/0x170 [usbcore] Aug 30 20:31:06 archangel kernel: [] ? hid_init+0x0/0xd1 [usbhid] Aug 30 20:31:06 archangel kernel: [] hid_init+0x93/0xd1 [usbhid] Aug 30 20:31:06 archangel kernel: [] do_one_initcall+0x39/0x1a0 Aug 30 20:31:06 archangel kernel: [] sys_init_module+0xbb/0x200 Aug 30 20:31:06 archangel kernel: [] 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 - Driver not connected Aug 30 20:31:23 archangel upsmon[2300]: Poll UPS [archangel_...@localhost] fai
