- Arch-general - lists.archlinux.org

[arch-general] NetworkManager, DHCP and DNS
by Guillermo Leira 02 Oct '12

02 Oct '12

Hello! I have been using wicd for a long time. I have installed and enabled NetworkManager service (with systemd). It seems to work, but I have found that when asking for a DHCP address, it does not register the conexion in the DNS server (as wicd does). I can't find anything about this issue... I have gone back to wicd, but it can't connect to my office's wifi (or I have been unable to configure it) and NetworkManager worked at the first attempt. Any suggestions? Best Regards, Guillermo Leira

3 5

Re: [arch-general] Updating iputils over NFS
by Paul Gideon Dann 02 Oct '12

02 Oct '12

On Monday 01 Oct 2012 14:22:41 Thomas Bächler wrote: > IMO, root file systems on NFS are a failure by design anyway - I worked > in such a scenario for years and it is a bad bad bad idea. While we > should fix easy problems such as this one, we should not spend too much > time on making this work. I'd be really interested in your reasons for this. I'm running a network- booted cluster, and things seem much easier using NFS for this than it would be to have a hard disk in each node and use puppet (or similar) for administration. Paul

2 6

[arch-general] glibc issues during first update in several months
by Erik Johnson 02 Oct '12

02 Oct '12

After several months of not updating my home server, I decided to run updates tonight. I still hadn't done the /usr/lib symlink move, so I followed the guide on the wiki like I did for my other boxes and still ended up borking my system. Think this is because I accidentally said "yes" to upgrading pacman before the other packages. I ended up finding this thread on the forum: https://bbs.archlinux.org/viewtopic.php?pid=1167283 After booting with a rescue disc and untar-ing the package into my root partition as that thread suggested, I was able to get booted back up and continue with the upgrade. However, once I got to the point where I do the final pacman -Su, I got a bunch of file conflicts: error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem glibc: /usr/include/bits/byteswap-16.h exists in filesystem glibc: /usr/include/bits/epoll.h exists in filesystem glibc: /usr/include/bits/eventfd.h exists in filesystem glibc: /usr/include/bits/hwcap.h exists in filesystem glibc: /usr/include/bits/inotify.h exists in filesystem glibc: /usr/include/bits/poll2.h exists in filesystem glibc: /usr/include/bits/signalfd.h exists in filesystem glibc: /usr/include/bits/socket_type.h exists in filesystem glibc: /usr/include/bits/sysctl.h exists in filesystem glibc: /usr/include/bits/timerfd.h exists in filesystem glibc: /usr/include/stdc-predef.h exists in filesystem glibc: /usr/include/sys/auxv.h exists in filesystem glibc: /usr/include/sys/elf.h exists in filesystem glibc: /usr/include/sys/vm86.h exists in filesystem glibc: /usr/include/uchar.h exists in filesystem glibc: /usr/share/i18n/locales/mag_IN exists in filesystem Errors occurred, no packages were upgraded. Is it safe to run the pacman -Su with --force since these files are all owned by newer glibc on my other Arch boxes? % for file in /usr/include/bits/byteswap-16.h /usr/include/bits/epoll.h /usr/include/bits/eventfd.h /usr/include/bits/hwcap.h /usr/include/bits/inotify.h /usr/include/bits/poll2.h /usr/include/bits/signalfd.h /usr/include/bits/socket_type.h /usr/include/bits/sysctl.h /usr/include/bits/timerfd.h /usr/include/stdc-predef.h /usr/include/sys/auxv.h /usr/include/sys/elf.h /usr/include/sys/vm86.h /usr/include/uchar.h /usr/share/i18n/locales/mag_IN; do pacman -Qo $file; done /usr/include/bits/byteswap-16.h is owned by glibc 2.16.0-4 /usr/include/bits/epoll.h is owned by glibc 2.16.0-4 /usr/include/bits/eventfd.h is owned by glibc 2.16.0-4 /usr/include/bits/hwcap.h is owned by glibc 2.16.0-4 /usr/include/bits/inotify.h is owned by glibc 2.16.0-4 /usr/include/bits/poll2.h is owned by glibc 2.16.0-4 /usr/include/bits/signalfd.h is owned by glibc 2.16.0-4 /usr/include/bits/socket_type.h is owned by glibc 2.16.0-4 /usr/include/bits/sysctl.h is owned by glibc 2.16.0-4 /usr/include/bits/timerfd.h is owned by glibc 2.16.0-4 /usr/include/stdc-predef.h is owned by glibc 2.16.0-4 /usr/include/sys/auxv.h is owned by glibc 2.16.0-4 /usr/include/sys/elf.h is owned by glibc 2.16.0-4 /usr/include/sys/vm86.h is owned by glibc 2.16.0-4 /usr/include/uchar.h is owned by glibc 2.16.0-4 /usr/share/i18n/locales/mag_IN is owned by glibc 2.16.0-4 -- -Erik "For me, it is far better to grasp the universe as it really is than to persist in delusion, however satisfying and reassuring." -- Carl Sagan

2 2

[arch-general] Message rejected
by Leonidas Spyropoulos 01 Oct '12

01 Oct '12

Hey all, l'm trying to send a patch over to arch-projects mailing list and it's rejected from filters. I added to subject the [archweb] as instructed from irc channel. This is my full subject: [archweb] [PATCH] Update Readme with Troubleshoot guide for SQLITE and POSTGRES Any idea why? Leonidas

3 3

[arch-general] Updating iputils over NFS
by Paul Gideon Dann 01 Oct '12

01 Oct '12

I'm having an issue updating a system that boots over NFS. Attempting to upgrade the iputils package results in the following: ---8<------------------------------- (1/1) upgrading iputils [###########################] 100% Failed to set capabilities on file `usr/bin/ping' (Operation not supported) usage: setcap [-q] [-v] (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>) <filenameN> ] Note <filename> must be a regular (non-symlink) file. Failed to set capabilities on file `usr/bin/ping6' (Operation not supported) usage: setcap [-q] [-v] (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>) <filenameN> ] Note <filename> must be a regular (non-symlink) file. ---8<------------------------------- I suspect this is something to do with NFS not supporting the capabilities that setcap is trying to use, but I admit I haven't encountered capabilities before I ran into this issue, so it's just a guess. Has anyone else seen this problem, or does anyone have an idea how to fix it? Paul

3 4

[arch-general] ArchHaskell: Testing repo built with GHC 7.6 available
by Magnus Therning 01 Oct '12

01 Oct '12

This is for all the Haskell users on the list who still haven't made it to the ArchHaskell list[1]: There is now a repo built with GHC 7.6: [haskell-testing] Server = http://www.kiwilight.com/haskell/testing/$arch At the moment it's only available for x86_64--building for i686 is happening as I write this and will hopefully be available within a day. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay

1 1

[arch-general] Mailing list closed for 24 hours
by Allan McRae 01 Oct '12

01 Oct '12

I am invoking the easy way to end flamewars... This mailing list will be shut down for the next 24 hours. Any messages sent to the list will go to /dev/null. Once the list is reinstated, I will automatically ban any person who sends an email that is not asking for help or providing help. Allan

19 34

[arch-general] want to try systemd but need some advice
by Fons Adriaensen 30 Sep '12

30 Sep '12

Hello all, During the past days I've been reading the sytemd manpages, and I'm more or less prepared to reconfigure one the systems I manage to use systemd. The main thing that scares me off is the 'consolekit style' login management of systemd's logind. In particular the following (from <http://www.freedesktop.org/wiki/Software/systemd/multiseat>): * A session is defined by the time a user is logged in until he logs * out. A session is bound to one or no seats (the latter for 'virtual' * ssh logins). and * Note that logind manages ACLs on a number of device classes, to allow * user code to access the device nodes attached to a seat as long as the * user has an active session on it. In the context I'm working in the whole 'seat' and 'session' thing, as far as I can understand it, doesn't make much sense. An absolute requirement for the system I'd want to test systemd on (and for many others I manage) is that there should be *no* difference at all between a 'local' login and one via ssh. Whatever a user is allowed to do or access should not depend on how he/she logs in, but only on his/her unix login and group membership. Root can do all he wants, normal users are as restricted as possible, and any exceptions to that are configured via /etc/sudoers and nothing else. In particular there's no place for polkit or anything similar here. I'd want things to be configured that way 'once and for all', meaning that a) I'm not really looking forward to having to do this for each and every device or command, and b) that a routine system update (a frequent enough event on an Arch system) must not be able to modify this policy. >From reading the avaiable docs I'm not convinced this will be possible, in particular since the docs concerning logind are rather incomplete (where are those ACLs defined for example). And 'ping Lennart if you need more info' as suggested, is not really a sustainable solution IMHO. So my question is: a) is it possible to configure a system as I want it, and b) if yes, how ? TIA, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

5 7

[arch-general] Open-source Radeon drivers status: HD7600M / HD7520G
by Robbie Smith 30 Sep '12

30 Sep '12

Hi all I've got a laptop with dual graphics: AMD A6-4400M processor with HD7520G "built in" (?) and HD7600M dedicated GPU. At the moment I'm using the Catalyst drivers that Vi0L0 packages[1], and it works quite well. I can switch which card I use (albeit with a restart of X), so I can enable the dedicated graphics only when I need it. I was wondering what the status of the open-source drivers are for these cards, and how they compare to the Catalyst ones. The Xorg wiki has a feature table[2] which seems to indicate that it should work (Wikipedia says the cards are part of the Northern Islands family), but I tried using xf86-video-ati on initial install and got only a black screen. Asides from KMS, what else does the open-source driver offer? Robbie [1] https://bbs.archlinux.org/viewtopic.php?id=57084 [2] http://www.x.org/wiki/RadeonFeature

1 0

[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