Re: [arch-general] Vim configuration: custom runtimepath + ftdetect
On 14.02.14 at 14:36, Emil Lundberg wrote: On Fri, Feb 14, 2014 at 3:21 AM, Jakub Klinkovský j@gmx.com wrote: I have moved ~/.vim to ~/.config/vim, the configuration is as follows: in ~/.profile: export VIMINIT='let $MYVIMRC=$XDG_CONFIG_HOME/vim/vimrc | source $MYVIMRC' in ~/.config/vim/vimrc: set viminfo+=n$XDG_CACHE_HOME/vim/viminfo set runtimepath=$XDG_CONFIG_HOME/vim,$XDG_CONFIG_HOME/vim/after,$VIM,$VIMRUNTIME Now, the thing is that files from ~/.config/vim/ftdetect/ are not respected. On the other hand, if I create ~/.vim/ftdetect/ (leaving the vimrc and everything else under ~/.config), the files are correctly sourced. Is this a bug or am I missing something here? According to ':help ftdetect' the runtimepath should be respected. For completeness: I have vim-hg-7.4.179 installed, the PKGBUILD is here: https://github.com/lahwaacz/archlinux-dotfiles/blob/master/Build/vim-hg/PKGBUILD Thanks, -- jlk I moved my vim config in exactly the same way a few days ago, but I use symlinks instead of configuration options. $ ln -s ~/.config/vim/vimrc ~/.vimrc $ ln -s ~/.config/vim ~/.vim Works just fine for me. /Emil Sure the symlinks work - but that will not help on the quest of cleaning my $HOME folder and totally kills the reason for moving into ~/.config/ -- jlk pgp38KmghwVTo.pgp Description: PGP signature
Re: [arch-general] Systemd email notifications
On Thursday 13 Feb 2014 17:58:05 Damjan Georgievski wrote: Yeah, I think it's possible to get systemd to poll a script, or there's always cron (or a timer unit) that should allow us to manually inspect a process and restart it if necessary. But it would be cooler if there were shortcuts to features that we see in Monit and other similar systems; something like this in a unit file: MaxMemoryThreshold=100M MaxMemoryCheckInterval=30 MaxMemoryIntervalThrehold=2 The memory is then checked every 30 seconds. When the unit exceeds this amount of RAM for 2 successive intervals, the unit is restarted. there is setting of ulimits in systemd, it's much more brutal though, will not wait for 30 seconds man systemd.exec Thank you; I didn't know about that, and it's very interesting. The limits are indeed a bit strict for server process monitoring. I imagine it would be really handy as a failsafe in embedded environments, though. The great benefit of them is that (as far as I can tell), it's the kernel that enforces the limits, so there's no polling involved. I suppose that the gold standard for monitoring would be a combination of the two: a userspace component (e.g. systemd or associated monitoring tool) registering to receive events from the kernel on certain resource thresholds for a process, so that e.g. time spent above RAM threshold could be monitored accurately in an event-based way, without polling. That would be awesome. Paul
Re: [arch-general] Updating the archlinux-keyring package
I do agree with that, i switched on a laptop which was off since september 2013 and i had some issue with some key. I had to update key, before having a sucessfull update. 2014-02-13 20:21 GMT+01:00 Leonid Isaev lis...@umail.iu.edu: Hi, Recently I had to fix a corrupted pacman db from a 3 month old livecd and realized that this process is not so innocent. Specifically, there is a chance to get a trojaned package on the system simply because the archlinux-keyring package on the iso is outdated. Of course, other similar scenarios are possible, e.g. a fresh install is made from an old livecd, or a server is updated after several months of uptime: new packages are pulled in but signature checks are made using the old keyring currently on the host. So, instead of relying on the discrete updates of archlinux-keyring, wouldn't is make more sense to have a systemd timer/cron job to frequently refresh pacman keyring? Thanks, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
[arch-general] KDE breakage with glibc 2.19-2
Is anyone else seeing breakage of KDE compositing with glibc 2.19-2? Large areas are unrendered: window contents and the plasma desktop are black, although my panel is visible. Seems OK when I turn of compositing. I've tried going back and forth, and it's definitely the glibc update that's causing the issue for me. Anyone else? Paul
Re: [arch-general] KDE breakage with glibc 2.19-2
On 14/02/14 11:12, Paul Gideon Dann wrote: Is anyone else seeing breakage of KDE compositing with glibc 2.19-2? Large areas are unrendered: window contents and the plasma desktop are black, although my panel is visible. Seems OK when I turn of compositing. I've tried going back and forth, and it's definitely the glibc update that's causing the issue for me. Anyone else? Paul Yes, I've seen this as well. Seems to occur intermittently for me. Gurnaik
Re: [arch-general] Updating the archlinux-keyring package
On 02/14/2014 03:00 AM, Plonky Duby wrote: I do agree with that, i switched on a laptop which was off since september 2013 and i had some issue with some key. I had to update key, before having a sucessfull update. 2014-02-13 20:21 GMT+01:00 Leonid Isaev lis...@umail.iu.edu: Hi, Recently I had to fix a corrupted pacman db from a 3 month old livecd and realized that this process is not so innocent. Specifically, there is a chance to get a trojaned package on the system simply because the archlinux-keyring package on the iso is outdated. Of course, other similar scenarios are possible, e.g. a fresh install is made from an old livecd, or a server is updated after several months of uptime: new packages are pulled in but signature checks are made using the old keyring currently on the host. So, instead of relying on the discrete updates of archlinux-keyring, wouldn't is make more sense to have a systemd timer/cron job to frequently refresh pacman keyring? Thanks, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pacman-key --refresh-keys ??
Re: [arch-general] Updating the archlinux-keyring package
Am 2014-02-14 12:00, schrieb Plonky Duby: I do agree with that, i switched on a laptop which was off since september 2013 and i had some issue with some key. I had to update key, before having a sucessfull update. A cronjob does not help you, when you're laptop is off.
Re: [arch-general] Updating the archlinux-keyring package
Am 14.02.2014 12:43, schrieb Don deJuan: wouldn't is make more sense to have a systemd timer/cron job to frequently refresh pacman keyring? pacman-key --refresh-keys ?? If you are paranoid enough that a former Arch developer or TU will be able to inject a broken package into a mirror, then it certainly helps you to run 'pacman-key --refresh-keys' regularly. You can also do so on the live CD. This will not automatically add new keys, but certainly remove trust from revoked keys. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Updating the archlinux-keyring package
2014-02-14 12:45 GMT+01:00 simon.br...@postadigitale.de: Am 2014-02-14 12:00, schrieb Plonky Duby: I do agree with that, i switched on a laptop which was off since september 2013 and i had some issue with some key. I had to update key, before having a sucessfull update. A cronjob does not help you, when you're laptop is off. I understand your point, i just wanted to illustrate with another practical exemple.
