Re: [arch-general] htaccess password
On Friday 30 Mar 2012 07:26:17 pete wrote: I need to generate them from the ground up although i know what the usernames will be I would be tempted to use pwgen. I'm a Ruby nut, so I'd probably use Ruby to split the output and pop it into a CSV to combine with the usernames, and then another script would take a CSV in and generate the crypt hashes. Paul
Re: [arch-general] Lock at shutdown with some kernels
On Friday 30 Mar 2012 15:06:53 Hector Martinez-Seara wrote: Hi, I've been having the same issue in a dell precision M4300. It started in some point of the kernel 3.1.x release. Since then from time to time the system does not shutdown unless using the power button to force a power off. Any ideas? I can provide more info if I'm instructed about what would be interesting to provide. The computer has arch 32bits for more than 2 years. Hector I believe I've heard reports that a BIOS upgrade solves this. I have this issue on a Dell Latitude E5520. I haven't got around to trying the upgrade yet, though. Paul
Re: [arch-general] Grub2
On Wednesday 28 Mar 2012 13:49:15 Kirill Churin wrote: Obviously, there are no fallback kernels, so grub-mkconfig doesn't find it. There never were any fallback kernels. The term fallback has always referred to the initramfs image, yet it used to detect them. Paul
Re: [arch-general] Grub2
On Wednesday 28 Mar 2012 13:45:46 Keshav P R wrote: https://bugs.archlinux.org/task/29037?getfile=8444 - Keshav This looks like exactly what is needed; thank you. Paul
Re: [arch-general] Grub2
On Monday 26 Mar 2012 02:18:53 Saurav Modak wrote: Have you tried manually adding it in grub.cfg BTW? Editing grub.cfg is a naughty thing to do with Grub2 :p The correct thing to do would be to add the fallback to /etc/grub.d/41_custom. However, Grub previously automatically detected the fallback correctly. I'm wondering why it doesn't now. Paul
[arch-general] Grub2
With the latest Grub2 (grub2-efi-x86_64 1:2.00beta2-2), it seems that grub- mkconfig is not picking up my fallback initramfs any more, so there's no fallback option in the boot menu. Has anyone else experienced this? Is there a way of fixing it? Thanks, Paul
Re: [arch-general] git software: howto remove files from history and its objects
On Monday 12 Mar 2012 13:17:11 F. Gr. wrote: Hi, I'm a new user of git software. I imported a mercurial repository to a git repository. Now I want to remove some files from history and the objects in my repository. Are these the right commands? git filter-branch -d /dir1/subdir/ --index-filter 'git rm --cached -f --ignore-unmatch' -- --all rm -rf /git_repo/.git/refs/remotes/origin git reflog expire --expire=0 --all git gc --aggressive --prune=0 then (perhaps :-) I can push to my remote repository. I haven't tried the above commands yet because I don't want to break my repository. Don't forget you can easily copy your repository. Make a complete backup (cp -a is fine), and try your commands. If it doesn't work, just try again on a fresh repository until you get it right :) If you get stuck, ask again here. It'll be easier to help you if you actually run into a specific problem, and have some example output for us to look at. Paul
Re: [arch-general] ruby 1.9.3_p125-1 in [extra]
On Sunday 26 Feb 2012 17:44:51 Jan Steffens wrote: On Sun, Feb 26, 2012 at 5:17 PM, Thomas Dziedzic gos...@gmail.com wrote: On Sun, Feb 26, 2012 at 4:40 AM, Paul Gideon Dann pdgid...@gmail.com wrote: On Saturday 25 Feb 2012 14:04:03 Thomas Dziedzic wrote: If you run sudo gem install foo, it will install to /root/.gem/ruby Are you sure? Won't it install to your normal user's home, but with root privileges? Paul I'm sure Depends on what sudo does. gem will do the wrong thing if sudo leaves HOME set to your user's home (either via env_keep or sudo -E). Yep; you're absolutely right: # sudo bash -c echo \$HOME This returns /root. Paul
Re: [arch-general] ruby 1.9.3_p125-1 in [extra]
On Saturday 25 Feb 2012 14:04:03 Thomas Dziedzic wrote: If you run sudo gem install foo, it will install to /root/.gem/ruby Are you sure? Won't it install to your normal user's home, but with root privileges? Paul
Re: [arch-general] [arch-dev-public] Ruby directory clean up proposal.
On Tuesday 14 Feb 2012 01:53:01 Peter Lewis wrote: I think it's worth separating out the user and the admin in this argument. To install a gem system-wide, you have to do something like sudo gem install XXX, right? This is almost always a bad idea, IMO, and people hopefully won't do it at least during the normal run of working with ruby. Personally, I don't let gem mess with anything outside my home directory. I'm worried. I use sudo gem install to install gems system-wide. It's not practical to use Arch packages for this instead, because I can't rely on a given gem always being packaged for Arch. I also don't really see the point of packaging a package from another packaging system which already happily co- exists with pacman. I have no issue using gem to administer system gems, since they always stay in /usr/lib/ruby and don't interfere with the rest of the system (except for /usr/bin, admittedly). Can you clarify if you're planning to make it impossible to use gem to install system gems? I *really* want to avoid using pacman for system gems and gem elsewhere. It makes no sense to me. I'd rather use gem for all gems. Maybe a quick summary of the plans so far? Paul
Re: [arch-general] [arch-dev-public] Ruby directory clean up proposal.
On Wednesday 15 Feb 2012 08:59:10 Thomas Dziedzic wrote: /usr/lib/ruby/site_ruby - This directory is for user specific installation and should never be touched by the package manager. /usr/lib/ruby/vendor_ruby - ruby packages installed with pacman which aren't gems go here $HOME/.gem/ruby/[ruby_base_version] - default target when running gem install foo because --user-install is now in the gemrc file /etc/gemrc - contains gem: --user-install to install user installed gems with gem to $HOME/.gem/gems If the user chooses to install gems using gem, they will have to add the bin directory to the $PATH: export PATH=$PATH:$(ruby -rubygems -e 'puts Gem.user_dir')/bin. System wide installation of gems by default will be disabled. If you want system wide gems, either run gem with the --no-user-install flag like sudo gem install --no-user-install foo You can also install to the system wide location by removing --user-install from /etc/gemrc This all sounds mostly fine. I assume that sudo gem install will simply install the gem using root-owned files in the home directory, right? Paul
Re: [arch-general] Alps touchpad problems
Hi Mike, I have a Latitude E5520, and I suspect we have the same touchpad. This is the Kernel bug you'll be interested in: https://bugzilla.kernel.org/show_bug.cgi?id=14660 This is the patch I've been using to add support for my touchpad to the kernel for the past few releases: http://giddie.homeip.net/alps.patch If you want it, here is a pre-built 64-bit kernel module: http://giddie.homeip.net/psmouse.ko You can keep it anywhere you want, and just rmmod psmouse, and insmod psmouse.ko. I'm pretty sure this will do the trick for you. Paul On Thursday 09 Feb 2012 19:39:53 mike cloaked wrote: I am trying to get a laptop touchpad working properly with arch fully up to date as of today. The machine is a recent Dell Vostro and has an Alps touchpad. I can't get vertical scrolling to work in KDE, and the mouse cursor occasionally moves erratically. I have seen previous posts some time back recommending installing the psmouse-alps package from AUR, and indeed it would appear that the 3.3 kernel may have a working psmouse module. However for the moment with kernel 3.2.5 the touchpad is detected as P/S 2 Generic - instead of the correct detection. I have tried installing psmouse-alps and rebooting but it made no difference so I uninstalled it again. the Xorg log has: [16.850] (II) config/udev: Adding input device PS/2 Generic Mouse (/dev/inpu t/event8) [16.850] (**) PS/2 Generic Mouse: Applying InputClass evdev pointer catchal l [16.850] (II) Using input driver 'evdev' for 'PS/2 Generic Mouse' [16.850] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [16.850] (**) PS/2 Generic Mouse: always reports core events [16.850] (**) PS/2 Generic Mouse: Device: /dev/input/event8 [16.850] (--) PS/2 Generic Mouse: Found 3 mouse buttons [16.850] (--) PS/2 Generic Mouse: Found relative axes [16.850] (--) PS/2 Generic Mouse: Found x and y relative axes [16.850] (II) PS/2 Generic Mouse: Configuring as mouse [16.850] (**) PS/2 Generic Mouse: YAxisMapping: buttons 4 and 5 [16.850] (**) PS/2 Generic Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [16.850] (**) Option config_info udev:/sys/devices/platform/i8042/serio1/input/input8/event8 [16.850] (II) XINPUT: Adding extended input device PS/2 Generic Mouse (type: MOUSE, id 12) [16.850] (II) PS/2 Generic Mouse: initialized for relative axes. [16.850] (**) PS/2 Generic Mouse: (accel) keeping acceleration scheme 1 [16.850] (**) PS/2 Generic Mouse: (accel) acceleration profile 0 [16.851] (**) PS/2 Generic Mouse: (accel) acceleration factor: 2.000 [16.851] (**) PS/2 Generic Mouse: (accel) acceleration threshold: 4 [16.851] (II) config/udev: Adding input device PS/2 Generic Mouse (/dev/input/mouse0) [16.851] (II) No input driver specified, ignoring this device. [16.851] (II) This device may have been added with another device file. Does anyone have current experience with this issue and know the best way to work around the problem until the 3.3 kernel is released? Thanks
Re: [arch-general] Kmail 2 problems
On Wednesday 01 Feb 2012 08:44:25 P Nikolic wrote: I am getting the following error on mail check Local Folders: Error opening: This folder is missing . I also get complaints about unable to delete (long number) on Kmail2 startup not sure if it is related but i have also had big problems with Akondai when trying to add my saved calenders with warnings of file on disc has been changed writing backup file i wound up with over 3000 files in a few mins had hell of a job dealing with that Assuming you're using IMAP email, and are beyond caring about filters other account-specific options, I'd suggest closing KMail, deleting the e-mail account using AkonadiTray (or Personal Information in System Settings), and then stopping and starting Akonadi (using AkonadiTray) before adding the account again. That helped me when I ran into issues when I first switched to KMail 2. Paul
Re: [arch-general] Kmail 2 problems
On Wednesday 01 Feb 2012 15:30:15 P NIKOLIC wrote: Sorry for the top posting back to web mail cus Kmail2 just eats everything baring the junk . No worries. I am using pop3 i have at present that matter 7 pop3 accounts (bt do not do imap) on those 7 accounts there are several mailing lists like this one i use filters quite heavily to ensure that on arrival the mails all end up in the correct folders hence making life easy and convienient but this install of Kmail2 is a real pain . It is that bad i looked at Claws but that does not feel or look right and it's filters are unable to do the job of shifting mail around from what i have found The problem is almost certainly that it's got mixed up in the migration. This is the main outstanding issue with the Nepomuk and Akonadi frameworks, in my opinion. Could you describe what KMail is actually doing that makes it unusable? I know you've mentioned some error messages, but what are the actual symptoms? Does mail go missing, appear multiple times etc...? If you're at the point where you're considering switching to another client, I think you'd do better to back up as much as you can from KMail, and delete and recreate your accounts. It'll be a pain, because it'll destroy your filters, but it might be better than having to switch to another client. If you decide to do that, you may be able to salvage most of your mail by copying it into Local Folders before deleting the POP3 account. Paul
Re: [arch-general] Kmail 2 problems
On Wednesday 01 Feb 2012 15:51:57 P Nikolic wrote: Well if this gets thru it may well be getting there i have completely deleted all the accounts and re done them but getting used to that now so does not take long (all in my head now even the dang passwords full of all sorts) also the same with the filters . It got through :) I can sometimes end up with 2 or 3 copies of a message or a message will go straight to the trash can and as soon i i access it the can just empty's . then there is the one about the Local folder not existing and the unable to move message (message number) . If there are errors in reference to Local Folders, you might want to try deleting the Local Folders resource from Akonadi, and recreating it. I don't think the maildir is deleted when you do this, so you might want to consider emptying it before recreating the resource. On my system, the directory is ~/.local/share/local-mail. One thing i can not find right now is just where the Mail is supposed to be stored i can not find it at all. I don't think it's stored in a standard maildir any more, but I think the relevant files will be at ~/.kde4/share/apps/akonadi-mbox-resource-X. If none of this works, I think you need to think about deleting your Nepomuk database, assuming you're not too attached to any tags or ratings you've assigned to files. This will destroy all that kind of metadata, which is generally stored in Nepomuk these days. In order to do this, you need to close KMail, shut down Akonadi, and run this command: $ qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit Make sure that nepomukserver has exited. (It can take a little while, sometimes. You may even have to kill it.) Then you can move ~/.kde4/share/apps/nepomuk to some backup location and restart Nepomuk with: $ nepomukserver Then you can start Akonadi again, and then KMail. With any luck, that might help. Paul
Re: [arch-general] User actions following system package upgrades?
On Thursday 26 Jan 2012 11:26:11 Kevin Chadwick wrote: Paul Gideon Dann wrote: I know that due to the way the kernel is upgraded, it is best to save kernel upgrade until the system can be rebooted, Surely there is no point upgrading the kernel unless you are going to reboot thereby loading in the new kernel and you could keep the old modules. Well, I usually find it a bit of a pain to have to remember to update the kernel before rebooting. Also, since I usually suspend rather than shutting down, I have to actually remember to update the kernel and reboot at some point. I usually do that when a decent number of important packages get updated and I think I'm probably about due a reboot; I might as well. I wish there were a better metric for this, though. Paul
Re: [arch-general] GTK app appearance
On Thursday 26 Jan 2012 09:23:41 Peter G Nikolic wrote: I have been unhappy with the way a few GTK based programes i use looked Firefox Gftp and Bluefish , So i installed gtk-qt-engine-1.1-3 and whilst some of the problems have gone away i now have silly things like no highlighting of the bookmarjs when the mouse is over them no visable entry boxes and no scroll bars in Firefox (i did let the GTK Styles fonts) install the firefox scroll bar fix to no avail any ideas / fixes I use oxygen-gtk2 and oxygen-gtk3, which work flawlessly. The GTK version requires creating ~/.config/gtk-3.0/settings.ini with the following contents: [Settings] gtk-theme-name = oxygen-gtk Also, have you checked out: https://wiki.archlinux.org/index.php/Uniform_Look_for_QT_and_GTK_Applications Paul
[arch-general] User actions following system package upgrades?
I've looked everywhere, but I can't find any reference to what the accepted wisdom is: I know that due to the way the kernel is upgraded, it is best to save kernel upgrade until the system can be rebooted, since the running kernel will be unable to load modules because the modules directory (/lib/modules/version) changes when a new kernel package is installed. For this reason, I have the linux package in my IgnorePkg line in pacman.conf, and upgrade it explicitly before a planned reboot. However, for what other packages is this true? I also have udev in IgnorePkg, but is this necessary? Is it safe to upgrade udev without rebooting? I suspect that certain rules may disappear or change, and the running udev may not be happy about that. I'm guessing it's also best to shut down X and restart DBus after a DBus upgrade too, although in practice a reboot is usually simpler, and that it would also be sensible to reboot after a glibc upgrade too, although that's rare. Any other thoughts? Are these sorts of considerations documented anywhere? This issue of upgrading system packages while the system is running feels like a potentially dangerous situation to me. Are we lucky that it doesn't cause too much trouble, or are in-place upgrades specifically handled gracefully by core system components such as udev? (I don't see anything special in udev's install script.) I suspect that most of us shrug it off and reboot only when we see breakage, but I hope you agree that's not a very safe way to work. Paul
Re: [arch-general] Kernel 3.2.1 woes
On Sunday 22 Jan 2012 21:39:31 Norbert Zeh wrote: On my Core i7 Dell Latitude 6510 laptop using the on-chip graphics chip and the 1920x1080 laptop screen, everything is fine until I suspend the machine to RAM. When resuming, I get a black screen and not even rebooting brings the screen back to life. I have to turn the machine off and then back on. Everything's working fine on my Latitude E5520 (HD3000 on-board GPU) with Linux 3.2.1-1. No problems resuming from suspend. Paul
Re: [arch-general] 3 errors not sure of .
On Sunday 08 Jan 2012 12:59:18 Peter Nikolic wrote: I cant even get the new stuff to take my old data from KDE 4.6.5 (4.6.5) release 7 . Yeah, migrations are probably the trickiest area, because it's a one-time thing. What exactly are you trying to migrate, and what happens now? Paul
Re: [arch-general] 3 errors not sure of .
On Sunday 08 Jan 2012 08:25:59 Peter Nikolic wrote: biggest problem now is this silly new email address book and organiser think and the FAILED attempt to make them use a commom data source , Dunno what the KDE devs were day dreaming of when they came up with that one it's a complete disgrace There have been a few hiccups with the changes that were required for shared data storage, but I agree with the KDE devs that it simply makes sense for things to move in that direction. I'm very excited about things that are in the pipeline that are possible because these sorts of changes were made. Enjoy your KDE; it's awesome, and it's going to get awesomer :) Paul
Re: [arch-general] About cron utility
On Saturday 07 Jan 2012 16:07:44 Andreas wrote: Does someone know if cronie does support running missed jobs automatically (asynchronous job processing)? I think that's why Cronie ships with Anacron. The latter is supposed to deal with those cases, I think. It's largely the split implementation that puts me off Cronie. Paul
Re: [arch-general] About cron utility
On Sunday 08 Jan 2012 10:29:01 Heiko Baums wrote: fcron runs missed jobs if bootrun is set at the beginning of the line in fcrontab. fcron has cron and anacron features all in one and works perfectly. I've heard quite a few good things about fcron. Am I right in thinking it has some slightly different syntax? I think it was rejected as Arch default for that reason, but I may be misremembering. Paul
Re: [arch-general] About cron utility
On Saturday 07 Jan 2012 11:49:48 éæè¾ wrote: Which cron utility should I use,cronie or dcron? Cronie in base group seems has a separate anacrontab in /etc which is not kiss I think? If anacron functionity has been included in dcron by default, May be dron is a good choice? I would recommend dcron. It did have some issues around that time with some long-standing bugs that Jim didn't have time to work on. Cron daemons aren't known for their fast-paced development; he was the only guy working on it and was busy with other stuff for a while. A couple of us eventually jumped into the code to help him, and all the known bugs were squashed. I've been using dcron on a production system at work, as well as my home server and laptop, and haven't had any problems since that time. I believe the Arch devs were too quick to switch to cronie, but that's done now. I understand the reasons, and with any other package it would have made sense, since upstream had been so quiet. Dcron is unusual, though, in that upstream is an Arch user, and the project has been kind of tied to Arch for a while. Paul
Re: [arch-general] People that depend on Arch, etc deserve to die? - Allan McRae - Clarifications
On Friday 23 Dec 2011 05:32:25 Jonathan Vasquez wrote: I wanted to know what was he trying to say? Is he saying that Arch and other Arch-like distros aren't serious distros that aren't meant for production? I mean I understand that Arch is rolling release and all that, but it's packages are marked stable by their corresponding upstreams. I think the point is that it can be dangerous to use ArchLinux for critical applications, because there are occasional breakages during updates. That's simply because Arch doesn't have a development cycle including a QA phase. Distributions such as Debian can make certain guarantees about the stability of their software, because they only use older and thoroughly-tested software by default. However, I believe ArchLinux is a perfectly sensible choice for critical production environments, so long as appropriate measures are taken. For instance, there should be a failover server, or in a cluster configuration an Arch box should be removed from the cluster for updating, and tested before being reintegrated. It's just about being sensible. Arch is awesome for servers, though. It's light and easy to maintain. It's a lot more hands-on for more of the time than more stable distros, but doesn't have the pain of upgrades. I think it that balances it out. Paul
Re: [arch-general] Is there a clean solution to get completely rid of Pulseaudio?
On Friday 23 Dec 2011 11:45:23 Ralf Madorf wrote:
I'll use jack, no desktop sound, no Skype etc., just pro and consumer
multimedia apps, flashplayer.
There hopefully is a way to fake that PA is installed.
Hi Ralph,
I have no idea if this will work for you but try this:
1) Create an empty directory.
2) Create a file named PKGBUILD inside that directory, with the following
content:
pkgname=pulseaudio-dummy
pkgver=1.0
pkgrel=1
pkgdesc=A dummy packages that pretends to provide pulseaudio.
arch=('any')
url=
license=('BSD')
provides=('pulseaudio')
conflicts=('pulseaudio')
source=()
3) At the command-line, in that directory, type:
# makepkg
# pacman -U *.pkg.*
(You may need to use sudo for that last command, or switch to root first
using su -.)
This should install a package named pulseaudio-dummy, which contains
absolutely nothing, but claims that it satisfies the dependency pulseaudio.
This *might* fix your problem, but it might also cause GNOME to crash. I don't
use GNOME, and I don't know enough about its dependency on pulseaudio to be
certain what will happen.
I hope this helps,
Paul
Re: [arch-general] Is there a clean solution to get completely rid of Pulseaudio?
On Friday 23 Dec 2011 21:02:43 Allan McRae wrote: I like GDM. I don't like login managers where I can't browse the users. Good to see you did you research on other login managers... I don't think this kind of sarcasm is going to help Ralph, and is likely to make him more frustrated, which will just make you more frustrated. Ralph, I really suggest you check out SLiM or LightDM. Ubuntu is replacing GDM with LightDM. I'm pretty sure that means it's at least as good... Paul
Re: [arch-general] Is there a clean solution to get completely rid of Pulseaudio?
On Friday 23 Dec 2011 12:06:37 Kwpolska wrote: Dear idiot, I'm kinda wondering why you aren't filtered from my mailbox yet. [..] I-M-P-O-S-S-I-B-L-E. Period. Seriously? It's comments like this that make me wonder if subscribing to this list is really worth it. At least you did go on to provide some useful information, albeit in a if I MUST stoop down to your level kind of tone. My suggestion is: (a) stop whining; or (b) learn how to code and cut out all sound stuff out of gnome-settings-daemon. No matter what you choose, there is one more option, which is much better: GET OUTTA HERE and use Debian if you like it so much. Not right? Then buy a Mac. Or Windows if you want to. PERIOD. Wow. I'm truly mortified that the Linux world is associated with behaviour like yours. What gives you the right to talk like that to *anyone*, let alone someone who came to us for help? Paul
Re: [arch-general] Is there a clean solution to get completely rid of Pulseaudio?
On Friday 23 Dec 2011 14:34:21 Ralf Madorf wrote: ... OT: OTOH I don't really understand how it works or why it seemingly won't solve some PA issues when it's running. I think you need to use it to invoke other programs: # pasuspender startx or maybe inside .xinirc: exec pasuspender startxfce4 Paul
[arch-general] USB Buffering Issue
Hello all, I've been having some trouble with USB drives in the last few months. When copying files onto a device, the copy appears to be instantaneous, but is clearly buffered by the kernel. If I unmount the drive, all appears well, but then removing the device results in corruption. In order to work around this, I have to run sync before unmounting the device. Any ideas what might be causing this, or how to fix it? It would be nice to get a *real* progress bar when copying large files, instead of a quick flash followed by a boring minute or more of staring at sync. Paul
Re: [arch-general] USB Buffering Issue
On Friday 02 Dec 2011 11:54:45 Timothy Redaelli wrote: Hi, by default linux mounts the devices with the async option. You can mount using the sync option, so you are sure that the I/O is made synchronously. Just remember: In case of media with limited number of write cycles (e.g. some flash drives) sync may cause life-cycle shortening. (from man 8 mount) Yes, that's probably it. I don't see sync in the mount options, so I'm guessing it's being mounted async. Shouldn't udev be taking care of this for usb drives? By the way, I'm mounting the drive via udisks (from KDE). So noone else is seeing this? Paul
Re: [arch-general] USB Buffering Issue
On Friday 02 Dec 2011 12:03:52 Nicolas Sebrecht wrote: No. udev is basically for devices discovery and naming them in /dev. Hehe; oh yeah, of course. Before trying any sync mount option, try to manually sync disks with the sync command to check if it fixes you issue. Yeah, everything's fine if I use the sync command before unmounting. Paul
Re: [arch-general] USB Buffering Issue
On Friday 02 Dec 2011 14:37:59 Nicolas Sebrecht wrote: How do you umount the USB device? I've done it both from KDE and the command line, but I don't think that really matters. It's the fact that large files appear to be copied instantly that is frustrating. Paul
Re: [arch-general] USB Buffering Issue
On Friday 02 Dec 2011 12:09:59 Timothy Redaelli wrote:
You can try to edit the udev mount options:
# echo 'ACTION==add, ENV{mount_options}=sync'
/etc/udev.d/rules.d/99-mount-options.rules
Then you must reload udev rules:
# udevadm control --reload-rules
This seems like the right thing to do, but I'd appreciate a little explanation
of the theory behind this fix. I haven't played around much with udev rules so
far. However, this looks like it might mount *all* disks with the sync
option. Could you explain how it's supposed to work?
I would have thought that, as was mentioned earlier, udev wouldn't be
responsible for mount options. Wouldn't that be handled by udisks somehow?
I've tried a mount -o remount,sync ..., and that fixes the issue, so it's
just a question of figuring out why USB drives aren't getting the sync option
automatically. It used to work OK until about 3/4 months ago. Maybe a new
udev broke this behaviour on my machine?
Paul
Re: [arch-general] USB Buffering Issue
On Friday 02 Dec 2011 16:31:47 Rogutės Sparnuotos wrote: There can't be any corruption after a successful unmount. 1. Run sudo umount /path/to/mounted/dir; echo returncode=$? 2. If you see 'returncode=0' on the last line, continue with 3. 3. Remove your USB drive. 4. Attach your USB drive. 5. If you see data corruption, it's one of: * faulty/misbehaving USB dongle (test with another USB device); * bad filesystem on your USB device (test with a freshly created one); * a bug in Linux kernel (report upstream). Yeah, umount seems to work correctly. I misinterpreted the fact that KDE reports an immediate unmount, but the device is not actually unmounted yet. That's probably a KDE fail. It's still odd that it used to work OK, though. The 'flush' and 'sync' mount options are not needed under normal circumstances (as in don't use if you don't know what you are doing). Well, without sync, I get incorrect progress bars when copying large files, and cp returns near-instantly. This happens even with flush. That doesn't seem right to me. Is that what you normally see? Maybe my expectations are wrong. Paul
Re: [arch-general] USB Buffering Issue
On Friday 02 Dec 2011 17:03:12 Rogutės Sparnuotos wrote: Yes, copying with midnight commander or with cp returns immediately [*]. I copy files from different directories, run umount and then wait for it to return. Yet I mount my phone with 'sync', because transferring is very slow and I want to observe progress. I believe that the situation with progress bars could improve with the 'flush' option (provided you copy tens to hundreds of megabytes), but I didn't try it. OK, then I think the issue is really the fact that KDE makes it look like unmount is complete when in fact it isn't. Thanks for your help.
Re: [arch-general] pacman new generation
On Tuesday 22 Nov 2011 12:20:25 Magnus Therning wrote: - Many of these languages improve the ability to reason about the behaviour of the program. This _can_ improve quality. HOWEVER, pacman doesn't strike as a tool that suffers from bad quality, there seems to be a development team that fully understand the crucial role that pacman plays in Arch and they behave accordingly in relation to rolling out updates. We should also bear in mind that most of what Pacman does is speed-critical database-like operations. I'm a huge Ruby fan, but I'm happy to admit that it's crazy slow compared to C. It simply doesn't make sense to rewrite it in another language; C is just about as fast as you can get. However, it *does* make sense to move most of the performance-critical sections into a shared library, for which bindings can be written for other languages. That way, you can quickly play with some concepts and write tools in easier languages on top on the library. That's actually pretty much what has been done already. Paul
Re: [arch-general] KDE: shortcut configuration broken
On Monday 07 Nov 2011 11:25:08 Alessio 'Blaster' Biancalana wrote: Hi archers and KDE users, Can I have confirm of a strange behaviour in my KDE? I can't open, in KControl (the control center), the shortcut and gestures configuration dialog: when i double-click the item, KControl freezes. Sometimes the configuration center for shortcuts opens up itself after a lot of time. What's happening? Bug? Other? Enlight me please. It seems to be working OK for me. Do you get any messages if you run systemsettings from a console? Paul
Re: [arch-general] KDE: shortcut configuration broken
On Monday 07 Nov 2011 12:40:44 Alessio 'Blaster' Biancalana wrote: I'm sorry, now it seems to be ok for me too. A reboot, and all is over :) Kmixer wasn't in its place, and I didn't manage to launch softwares with my custom shortcuts; now I can. I will inform you if it happens again, thanks for your feedback! It sounds like maybe kded4 crashed. If it happens again, try checking to see if the kded4 process is running. If it is, it might be hanging using 100% CPU. This has happened to me in the past, and has various side-effects. You can deal with that with: # killall kded4 kded4 Paul
Re: [arch-general] Programs Not Closing
On Wednesday 26 Oct 2011 10:53:18 Squall Lionheart wrote: Ever since the upgrade to KDE 4.7 several weeks ago, a lot of programs seem to hang in the Task Manager after I close them. They will remain for a long time or until I open another application. I also have an occasional application crash when I shutdown. Unfortunately, the crash message tells me nothing of what program is crashing and I'm not sure if it's related. I've seen behaviour that I *think* is what you're describing. I've seen a few applications remain in the task bar, but I'm almost certain that it's simply a bug in the plasmoid. Any kind of update to the window list in the task bar (e.g. moving a window onto another screen and back) removes the phantom task bar entry. Paul
Re: [arch-general] [signoff] linux-3.1-2
On Wednesday 26 Oct 2011 12:05:08 Thomas Bächler wrote: This is the output of dmesg -l err: [1.882959] [drm:ironlake_update_pch_refclk] *ERROR* enabling SSC on PCH [ 10.336917] ACPI: Invalid _PSD:coord_type [ 10.338144] ACPI: Invalid _PSD:coord_type [ 10.338784] ACPI: Invalid _PSD:coord_type [ 10.339422] ACPI: Invalid _PSD:coord_type [ 12.546241] usb 1-1.6: device descriptor read/64, error -32 The first message is new in 3.1, the ACPI messages appeared with 3.0, and the last one is a sporadic message that I already got with 3.0. The SSC on PCH message may be a debug message that was accidentally left in. See: https://lkml.org/lkml/2011/9/19/80 Paul
Re: [arch-general] System Cron jobs not running
On Friday 21 Oct 2011 20:05:18 R7h0re4 wrote: Just to be safe I added the full path to my script for the commands it is calling. I also looked at the wiki again and nothing mentions the use of Cronie, and system cron jobs. I also checked the file /var/spool and see anacron which has the sub directories. I would almost say this wiki needs some updating and would assist once we get it working. I suggest removing cronie / anacron and switching to dcron. It used to be the default, but was switched because it was perceived to be buggy. However, all known bugs have now been fixed, and it's been running reliably for me for ages. I trust it more than cronie / anacron. Paul
Re: [arch-general] Wiki forum down?
On Monday 24 Oct 2011 10:30:26 Taylor Hedberg wrote: Apologies if I've missed something obvious, but both the wiki and forum seem to have been down for at least a few hours now (I think they are located on the same host). Does anyone know what the situation is? They both look fine to me. Maybe an issue with your local DNS? Paul
Re: [arch-general] Wiki forum down?
On Monday 24 Oct 2011 09:38:19 Dwight Schauer wrote: On Mon, Oct 24, 2011 at 9:35 AM, Paul Gideon Dann pdgid...@gmail.com wrote: On Monday 24 Oct 2011 10:30:26 Taylor Hedberg wrote: Apologies if I've missed something obvious, but both the wiki and forum seem to have been down for at least a few hours now (I think they are located on the same host). Does anyone know what the situation is? They both look fine to me. Maybe an issue with your local DNS? Paul It is down for me to. That's odd; they're both down for me too, now. I do use dnsmasq for DNS caching, so maybe that has something to do with why it worked for me the first time? Paul
Re: [arch-general] Adopting start-stop-daemon in archlinux
On Thursday 08 Sep 2011 12:08:30 Clemens Fruhwirth wrote: I propose to switch to start-stop-daemon and deprecate the method above. http://clemens.endorphin.org/sshd-start-stop-daemon.diff is an example of an rc.d script ported to start-stop-daemon. The paradigm -- to my personal taste -- is clean and simple. The diffstat is negative LOC-wise. I like the idea; on first inspection it looks clean, simple, and elegant :)
Re: [arch-general] Content of new text file
On Wednesday 13 Jul 2011 15:00:37 Squall Lionheart wrote: When using Dolphin in KDE4 to *Create New Text File...* the new file is not empty, it contains a space and a newline character. I wonder if that's to do with MIME types? With a space and a newline, the file is detected by file as ASCII text rather than empty. A single newline is detected as very short file (no magic), so probably the space-newline combo is the shortest file that can be automatically detected as text. It might be handy to have the option to Create New = Empty File though, although I don't think I've ever needed to do this outside a terminal myself. Paul
Re: [arch-general] {external, general}ized hooks in key packages [kernel26, ???] (WAS: Re: Reboot - Versioned Kernel Installs)
On Monday 13 June 2011 20:53:19 David Campbell wrote: Excerpts from Timothy L.'s message of 2011-06-13 15:10:16 -0400: ... I'm a novice when it comes to this kind of stuff, but adding simple hooks doesn't seem to needlessly complicate a user's system. It's something a user would never notice unless they actually needed to use the functionality it provided. Just to clarify, when people talk about keeping it simple and the Arch way, they are not talking about having a simple, clean interface for the user, they are talking about keeping the system itself simple, as to reduce the likelihood of bugs, to make maintenance simpler, to make extending the system easier, etc.. Also, the Wiki article on The Arch Way states the following: Arch Linux targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system. In my opinion, overwriting a working kernel with a version that has not yet been tested on the system, without performing a backup, makes the user's job of responsibility difficult. Providing hooks and the option to perform a backup empowers the user and enables him/her to be cautious if that's his desire. Paul
Re: [arch-general] Reboot - Versioned Kernel Installs
On Friday 10 June 2011 20:44:16 Mauro Santos wrote: Arch users have lived without the last good known kernel so far and without an -lts kernel until recently. IMHO it is a lot more advisable to have an install cd/usb, or even better, a custom install in some external media that can be used to boot the system in case something goes wrong or in case of emergency. Then you can just chroot into the broken install and fix the problem or tell pacman where the root and cache are located and fix things. To me, that just doesn't sound like a sensible rescue plan for a modern OS. I like tinkering and learning, but being forced to boot a CD, load dm-mod, bring up my LVM volumes, mount the root, bind proc, sys, and dev, chroot, and finally get pacman to install the last kernel? That's something I'd like to avoid unless I'm doing it for fun :) Paul
Re: [arch-general] hwclock and openntpd
On Saturday 04 June 2011 08:44:34 Jan de Groot wrote: On Sat, 2011-06-04 at 03:06 -0400, Yclept Nemo wrote: Perhaps openntpd does not set the hwclock. Therefore, should openntpd be used in conjuction with the hwclock daemon? That's true, and that's also the reason why Openntpd doesn't play well with Xen where all guest VMs will take over the clock from the host VM. With the normal ntp distribution that works, but with Openntpd you need something to push the changes to the hwclock. I've found this gnawing at me since I read it. I originally started using OpenNTPD because it was smaller, lighter, and easier to configure. However, it's disappointing that it doesn't deal better with the hardware clock. Searching around for more information, I discovered that OpenNTPD is not currently well supported for Linux, and the portable version that our package is based on is lagging significantly behind the mainline. I've heard a few people mention Chrony as a good alternative, and I like the sound of it. There's an AUR package, but no Wiki entry. Has anyone given Chrony a shot, or have any strong opinions about it? Paul
Re: [arch-general] Reboot - Versioned Kernel Installs
On Friday 10 June 2011 14:05:14 Yaro Kasear wrote: Another agreement from me here. Also, may I also add that a great deal of Arch users have /boot in a (tiny) partition to start with and can't really KEEP that much stuff in there? Keeping old kernels would definitely screw their systems up and keep them from upgrading with any ease. I have two kernels in /boot at the moment, and that takes 32MiB. My /boot partition is 200MiB, which is pretty generous as far as separate /boots go. That gives me room for 12 kernels. I'm not sure many would have a /boot smaller than 100MiB, and can't see *anyone* partitioning a /boot to less than 32MiB. I don't think space is a concern when we're talking about 2-3 kernels (current, previous, and possibly a custom build.) Paul
Re: [arch-general] Reboot - Versioned Kernel Installs
On Friday 10 June 2011 14:03:32 Yaro Kasear wrote: On Friday, June 10, 2011 04:26:21 Robert Howard wrote: Why not just copy the old kernel image, modules and initrd image somewhere by hand before you upgrade kernels. If we try to make this automated it isn't going to be kiss. I used to do this way back in the day by including the entire kernel version in the pkgver and giving the images longer names. It was possible to have concurrently installed kernels. Check out how some of the AUR kernels manage to be the same kernel version as the official without causing issues. +1 on this. If you really need the old kernel, why not make sure you back up the old one and its image before upgrading instead of inconveniencing other users and the developers for a feature only a minority even wants? Because it's painful to go through that every time a new kernel update comes along. Also, I think you're underestimating the interest in this. This list will typically contain the most advanced Arch users, who are confident rescuing their system from a bad kernel upgrade. I'm sure there are plenty of Arch users out there that aren't reading this list, but for whom this feature could save them a lot of time and effort. Just because most of *us* can probably fix this in our sleep, doesn't mean it's right for Arch users in general. Also, I wonder what happens if power is lost whilst pacman is installing a new kernel? I haven't tried this, but it wouldn't surprise me if the system ended up with a truncated kernel that wouldn't boot. That's a bug right there, although it's a pretty tiny corner case, granted :) Paul
Re: [arch-general] Reboot - Versioned Kernel Installs
On Thursday 09 June 2011 00:04:09 Heiko Baums wrote: schrieb Oon-Ee Ng ngoonee.t...@gmail.com: Such a patch would also have to copy the modules (which aren't under kernel26's 'purview'). For example, nvidia gets upgraded on a major version kernel update, the old kernel which has been renamed doesn't 'work' graphically anymore. Yeah, I think this is starting to go beyond what can sensibly be implemented in the install script. I'm putting my voice behind versioned kernels. If we can define the number of old kernels to keep in rc.conf, that idea is actually a superset of my desire to keep a pre-upgrade kernel, without cluttering /boot too much. The old kernel image is just to get the system booted to being able to repair the system (downgrading the kernel package again or whatever). The modules shouldn't be necessary for this. I'm afraid I don't agree with this; I'd like to be able to boot to a fully- usable system from the pre-upgrade kernel, in case the new kernel is broken. I'm using Arch Linux for about 4 years now and before then I was using Gentoo for about 6 years. I never had one single issue with a kernel upgrade particularly not such an issue which caused a boot failure. Well, it's happened to me, and it *could* happen to you. Better to prevent the situation, don't you think? If this really happens - in the very rare cases - then it's always possible to boot from a LiveCD. This is what I've always had to do, but I don't like the idea of relying on always having my LiveCD handy. LTS gets around this, but it doesn't feel like the correct solution to a failed upgrade; more of a workaround. If someone is really so afraid he can easily install kernel26-lts or another kernel package and, of course, he definitely shouldn't use the [testing] repo. Unfortunately, my new laptop has a buggy UEFI implementation and will only boot 3.0.rc1 or newer. Who knows if my hardware will fail to boot with the next release? This worries me, so I'd like to have known-to-work kernels lying around just in case. Paul
Re: [arch-general] Reboot - Versioned Kernel Installs
On Thursday 09 June 2011 14:07:45 Yaro Kasear wrote: On Thursday, June 09, 2011 05:31:06 Paul Gideon Dann wrote: Well, it's happened to me, and it *could* happen to you. Better to prevent the situation, don't you think? Again: Purpose of fallback image and lts kernel. Jacking up /boot with dozens of old kernels is not a needed or desirable solution. I don't think that's the case; the purpose of LTS is to provide an extra- stable kernel that is less likely to break between upgrades (hence long-term support). It might be good to have around for rescue, but that's not the same as having a last-known-working-configuration kernel. The fallback initrd is completely irrelevant, because as far as I'm aware, that only protects against initrd configuration mistakes and unplanned hardware alterations (e.g. after hardware malfunction). Arch development should never be centered around compensating for users' crappy hardware. There are ways to fix UEFI without annoying the other users of Arch with cluttered boot partitions. If you want old kernels that badly, use lts or go to a distribution that implements this bad feature. It's not as though /boot needs to fulfill many other roles... And would you really label all new hardware crappy until it's well supported? Paul
Re: [arch-general] Reboot - Versioned Kernel Installs
I would really like to the kernel that is being replaced kept as a backup. If the latest kernel breaks your hardware, or something else goes wrong, I'd like to have the option of using the kernel that was just replaced, because it's known to work. I wouldn't want more than one old version of the kernel, though. Also, although the -lts kernel is good for this, it isn't intended to solve this problem, and isn't always a perfect fit. For instance, my new laptop has UEFI-related issues that are only being addressed in the *very* latest kernels. I'm not sure -lts would boot for me, but I know that my *current* kernel boots; seems a pity to throw it out it straight away on upgrade, before I can test that the new kernel boots OK... Paul On Monday 06 June 2011 18:23:50 Tom Gundersen wrote: On Mon, Jun 6, 2011 at 6:22 PM, Tavian Barnes taviana...@tavianator.com wrote: I have kernel26-lts installed as a backup kernel, and this is all that's really necessary for rolling back broken kernel updates. I've been bitten by a BTRFS bug once and rolled back with -lts no problem. -1 from me on keeping multiple kernel versions installed; I really like that arch doesn't keep 6 old kernels around. I agree. The reason I am against keeping old kernels around is that we would not be able to test user space against all the possible combinations, so it would not be a good idea to suggest that we do (we do try to support all sorts of self-compiled kernels, but at least if you compile your own kernel it is pretty obvious that it will not be as well tested as the official ones). One possibility would be to do like upstream does and always rename the previous kernel to .old. That should keep the last known working kernel around while making it clear that it should not be relied on for day-to-day use (and that it will get overwritten on the next kernel upgrade so these things won't get old). That said, I'm not involved with packaging the kernel, so if you want anything to change with how it is packaged (maybe after this discussion is over), it would be best to file a feature request on FS. Cheers, Tom
Re: [arch-general] Reboot - Versioned Kernel Installs
On Wednesday 08 June 2011 15:45:21 Tom Gundersen wrote: On Wed, Jun 8, 2011 at 4:41 PM, Jelle van der Waa je...@vdwaa.nl wrote: If you want this, implement it! I have seen some discussions about it and it always tend to users wanting feature X or Y, but didn't commit to it. protip: iirc there are some threads about this on the mailing list, the forums and the bugtracker, start gathering info there. Implementing this should be almost trivial, it's just a patch to kernel26.install. I think if someone wants to see this feature, the best way would be to post a patch to arch-proje...@archlinux.org. That's true; I'll try to find some time to do this in the next week or so, if someone doesn't beat me to it. I was just expecting to contribute to the discussion regarding the best way to deal with kernel upgrades, but if you think this patch would be accepted, I'd be happy to provide it. Paul
