July 2012 - Arch-general - lists.archlinux.org

[arch-general] Possibility of including xorg input patch
by Kirill Churin 25 Jul '15

25 Jul '15

Can this patch https://bugs.freedesktop.org/attachment.cgi?id=33142 be applied to Arch's xorg? It solves famous problem https://bugs.freedesktop.org/show_bug.cgi?id=865 with broken keyboard input for users who use multiple keyboard layouts without any noticeable side-effects. It's known this patch has been applied in Ubuntu. -- Kirill Churin Jabber: reflexing(a)reflexing.ru, ICQ: 8163230, Skype on demand.

5 4

[arch-general] A little script to deploy dot files
by 郑文辉(Techlive Zheng) 26 Oct '13

26 Oct '13

[Inspired by tomd123@bbs.archlinux.org](https://bbs.archlinux.org/viewtopic.php?id=134622), I have wrote a small script to deploy the dotfiles acrossing viarous hosts, may be you guys are interested to have a look. Github: https://github.com/techlivezheng/dotploy Thoughts and advices are very welcome, cause my bash skills are still need much improving, there must be some ugly workaround. Regards, Techlive Zheng

2 3

[arch-general] Unable to add fonts to X
by D. R. Evans 29 Sep '12

29 Sep '12

I couldn't find a more appropriate place to ask this question. Please feel free to point me to such a place if one exists. ---- Using a completely up-to-date 32-bit arch system, I am trying to make some fonts available to X. My understanding of the process is: 1. Put the fonts in a directory. 2. Since these are scalable fonts, run mkfontscale in the directory. 3. Run mkfontdir in the directory. 4. run xset +fp <directory name> So what I did: 0. Created the directory ~/.fonts. 1. Put the fonts in ~/.fonts. At this point the contents of the directory looks like this (sorry about the wrapping): lrwxrwxrwx 1 n7dr users 39 Apr 22 17:08 CourierNewPSMTN7DR.ttf -> /home/n7dr/fonts/CourierNewPSMTN7DR.ttf lrwxrwxrwx 1 n7dr users 34 Apr 22 17:08 N7DR_SFTT1000.afm -> /home/n7dr/fonts/N7DR_SFTT1000.afm lrwxrwxrwx 1 n7dr users 34 Apr 22 17:08 N7DR_SFTT1000.pfb -> /home/n7dr/fonts/N7DR_SFTT1000.pfb 2. Ran mkfontscale in ~/.fonts. This created the file fonts.scale, which had the following contents: 33 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-adobe-standard CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-ascii-0 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-ibm-cp437 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-ibm-cp850 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-ibm-cp852 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-ibm-cp866 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-iso10646-1 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-iso8859-1 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-iso8859-10 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-iso8859-13 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-iso8859-15 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-iso8859-2 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-iso8859-3 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-iso8859-4 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-iso8859-5 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-iso8859-8 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-iso8859-9 CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-koi8-e CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-koi8-r CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-koi8-ru CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-koi8-u CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-koi8-uni CourierNewPSMTN7DR.ttf -monotype-courier new n7dr-medium-r-normal--0-0-0-0-m-0-microsoft-cp1252 N7DR_SFTT1000.pfb -misc-computer modern n7dr-medium-r-normal--0-0-0-0-p-0-adobe-standard N7DR_SFTT1000.pfb -misc-computer modern n7dr-medium-r-normal--0-0-0-0-p-0-ascii-0 N7DR_SFTT1000.pfb -misc-computer modern n7dr-medium-r-normal--0-0-0-0-p-0-iso10646-1 N7DR_SFTT1000.pfb -misc-computer modern n7dr-medium-r-normal--0-0-0-0-p-0-iso8859-1 N7DR_SFTT1000.pfb -misc-computer modern n7dr-medium-r-normal--0-0-0-0-p-0-iso8859-15 N7DR_SFTT1000.pfb -misc-computer modern n7dr-medium-r-normal--0-0-0-0-p-0-iso8859-9 N7DR_SFTT1000.pfb -misc-computer modern n7dr-medium-r-normal--0-0-0-0-p-0-koi8-r N7DR_SFTT1000.pfb -misc-computer modern n7dr-medium-r-normal--0-0-0-0-p-0-koi8-ru N7DR_SFTT1000.pfb -misc-computer modern n7dr-medium-r-normal--0-0-0-0-p-0-koi8-u N7DR_SFTT1000.pfb -misc-computer modern n7dr-medium-r-normal--0-0-0-0-p-0-microsoft-cp1252 3. Ran mkfontdir in ~/.fonts. This created the file fonts.dir, which was identical to fonts.scale. 4. One piece of documentation I read said that X automatically includes ~/.fonts in its path, but running xset q did not include ~/.fonts in the directory list. So I ran: xset +fp /home/n7dr/.fonts But now we come to the problem. This command returns: xset: bad font path element (#37), possible causes are: Directory does not exist or has wrong permissions Directory missing fonts.dir Incorrect font server address or syntax But: a. the directory obviously exists, and it has permissions rwx for the user. b. The directory contains the file fonts.dir c. The syntax looks OK. So what is xset complaining about? (I suspect that the problem lies in the *contents* of fonts.dir, since if I create a dummy version of the file, I don't receive the error. But since the file was automatically created, I don't know what might be wrong, nor how to correct it. Maybe my suspicion is wrong, though.) Doc -- Web: http://www.sff.net/people/N7DR

6 16

[arch-general] Glibc 2.16.0-2 and /lib problem : the answer ;)
by fredbezies 30 Aug '12

30 Aug '12

Well, Tom gave the answer. Boot on rescue-CD / rescue USB-key. Remove /lib. And create a symlink : ln -sf /usr/lib lib I think there will be a lot of problem for a lot of users when glibc 2.16.0-x will be uploaded on core. Well, I think I have to do this mistake. I *do* know that forcing wasn't a good idea :| -- Frederic Bezies fredbezies(a)gmail.com

11 18

[arch-general] Suspend to ram and uresume hook for systemd
by Myra Nelson 17 Aug '12

17 Aug '12

Since I'm still wading my way through some of the intricacies (read small details) and in view of the recent discussion on libcrypt, keysize, key values, and systemd; I've been using uswsusp-git from the aur and s2ram -f for my suspend command. /etc/suspend.conf has /dev/snapshot and /dev/sda4 (swap) for the image. Suspension and reboot have been working fine. After rebuilding my initramfs image with the uresume hook, when I tried to reboot today the boot process hung at waiting for libgcrypt. In my infinite wisdom, after testing the suspend and reboot several times before using the uresume hook, I had uresume in both images. I don't use encrypted volumes and never have. I chrooted in and rebuilt the initramfs image without the uresume hook, rebooted, and everything worked great. I tried using systemctl suspend from the wiki article. The machine goes down but won't come back up without a complete restart, fsck volumes that were not cleanly unmounted, etc. Since this is a desktop, I really don't need the suspend option, it's just nice to save a little electricity. The systemctl shutdown and sytemctl reboot work great. I admit to not having done a lot of research but based on the recent discussions and changes with systemd, does anyone know what caused this hiccup? Myra -- Life's fun when your sick and psychotic!

3 5

[arch-general] my Arch box randomly becomes irresponsible
by Not To Miss 09 Aug '12

09 Aug '12

Dear Arch users, I have latest Arch installed on my desktop at work. In recent two weeks, the system randomly "suspends" at night (I call it "randomly" because it didn't happen every night. And it seems to happen after a random period idle time) when I am off. I can't wake it up in the next morning thru mouse or keyboard. I tried to disable suspension and hibernation by editing /usr/share/polkit-1/actions/org.freedesktop.upower.policy to change from <allow_active>yes</allow_active> to <allow_active>no</allow_active> But it doesn't work. While I call it "suspend", I am not sure it suspend to RAM or hibernate to disk, because I find the CPU fan and power fan still spin normally. RAM light is also on. So it might be a video driver / setting related issue. For your information, I am using nvidia-302.17-2-x86_64 and have dual monitor set up with nvidia-utils-302.17-1-x86_64 This really bothers me a lot. Any help is appreciated. Thanks! -- Best, Zech

12 25

[arch-general] Skype locks up my system, not even sysrq keys work
by SanskritFritz 05 Aug '12

05 Aug '12

When I do a videochat in skype, the whole system freezes after a while. This while can be a couple to 10+ minutes. The system locks up usually when I start or close some other apps in the background. When it happens the screen doesnt change anymore, and the sound stutters the last half second over and over again. Nothing helps, not even the magic sysrq keys (REISUB), which otherwise do work (tested it). I suspect this could be a result of a new videocard in the system (the problem started around that time, when I swapped the old GeForce 7300 GS to a new 8600 GT), but everything else works flawlessly, 3D games, movies, compiz, everything, except skype. Is it possible that a hardware problem causes a problem of this magnitude only with skype? I couldn't find anything in the logfiles after reboot. There is no overheating of the nvidia card or cpu, I constantly check it with conky. Later I'm going to switch back to the old videocard, and test, to see if it is hardware related. Please help me to find the problem if software related. Cheers SanskritFritz

3 8

[arch-general] [signoff] btrfs-progs
by Tom Gundersen 05 Aug '12

05 Aug '12

Hi guys, Seems not many of us yet use btrfs, I therefore would like to ask if any users can signoff on the btrfs-progs in testing (i.e. verify that the package appears to work). In particular, I'm interested to hear if someone who uses btrfs-progs and initscripts from testing could verify that the multi-device support still works? If you have the btrfs hook in your initramfs, then please enable udev too and regenerate the image to verify that that also still works. For those who are interested: the change we made was to scan btrfs devices for multi-device support using udev rules as the devices appear rather than doing it unconditionally after "all the devices should be ready". This approach should hopefully be more reliable than the old one. Cheers, Tom

7 20

[arch-general] Texlive package install
by Arno Gaboury 03 Aug '12

03 Aug '12

Dear list, I use Texlive + Texmaker to write some documents. I can't find an easy and solid way to install new packages from CTAN.Package tlmgr from AUR couldn't compil on my box and will not do the job.Installing manually new packages doesn't seem to be a good idea and is not very straightforward. Thank you for any advice.

5 7

[arch-general] [arch-projects] [initscripts] [GIT] Arch Linux initscripts repository branch master updated. 2012.07.5-3-gf670511
by Myra Nelson 02 Aug '12

02 Aug '12

Tom: >From your latest update to the initscripts in the git repo. This makes sure that systemd supports some initscripts API's. With this patch, systemd will: * Parse and use DAEMONS and MODULES from rc.conf * Run rc.local and rc.local.shutdown on boot and shutdown respectively I have everything working but my network with I load manually. I'm using journalctl etc instead of syslog Since systemd parses the rc.conf file now the only thing I should need in the daemons line is [ network ]. Is that correct? I tried to shoot the message below to you on the arch-projects list, but don't have access on that list to send you mail, so here it is. Tom: Good job. The one suggestion I have comes from my bent for making sure people don't miss things. I would estimate 90 to 95 percent of Arch users wouldn't miss and most others won't unless they are in a hurry (me). Would you consider it over the top to change the following line The local timezone is configured by symlinking /etc/localtime to the correct zoneinfo file under to The local timezone is configured by *symlinking* /etc/localtime to the correct zoneinfo file under making symlinking show up in bold text. Myra -- Life's fun when your sick and psychotic!

2 3