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

[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

[arch-general] Newly installed system without uuidd user
by Rodrigo Rivas 29 Sep '12

29 Sep '12

Hello all! I know, this should go to the bugtracker, but I couldn't find the `arch-install-scripts` anywhere... so I'm bringing it here. I've just installed a new Arch in a VM using the new & improved `archlinux-2012.09.07-dual.iso`. It went quite well and painless but I noticed a weird error in the boot screen: [/usr/lib/tmpfiles.d/uuidd.conf:1] Unknown user 'uuidd' Right! There is no user 'uuidd' anywhere. The solution is actually easy: # pacman -S util-linux That reinstalls the package and recreates the user. So, if the `util-linux` package is correct, I reckon that is a bug in the `arch-install-scripts`, isn't it? Regards -- Rodrigo

2 2

[arch-general] task #31424: User git has home set to /
by coderkun 28 Sep '12

28 Sep '12

According to this bug https://bugs.archlinux.org/task/31424 I lost all my files yesterday. So this is a warning to all users who are wondering about the “git daemon user” – that is really a demon!

1 0

[arch-general] Bug with procps-ng or systemd?
by Simon Perry 28 Sep '12

28 Sep '12

/var/log/utmp is not being used. Updated procps-ng on the 24th, systemd 192 update on the 27th, but have only just noticed this. Running a "w" command no longer shows current logged in users. An strace of /usr/bin/w shows: access("/var/run/utmpx", F_OK) = -1 ENOENT (No such file or directory) open("/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) access("/var/run/utmpx", F_OK) = -1 ENOENT (No such file or directory) open("/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) I have searched FS but haven't found anything relevant, should a bug be lodged against procps-ng or systemd? -- Simon Perry (aka Pezz)

2 2

[arch-general] utmp MIA
by Jorge Almeida 28 Sep '12

28 Sep '12

I ran pacman -Syu yesterday, and now on boot the file /run/utmp is not created. Anyone else with this problem? (Yes, /var/run is a symlink to /run) (I also changed from grub2 to syslinux, but I suppose this has nothing to do with the problem; it boots fine. This is the only difference in installed software/configuration.) TIA Jorge Almeida

2 2

Re: [arch-general] The future of sysvinit in Arch: Call for Help
by G. Schlisio 27 Sep '12

27 Sep '12

>> -remove initscripts from the repos >> -no more developement in git and on arch-project ML > I don't see the benefit of doing that quickly, but if that's what you > guys want, it is fine with me. I would be in favor of initscripts > dying a natural death. > some people are stuck with initscripts for a while, letting it die naturally would be great for such usecases. i am running an arch server in a virtual private server where can not change the kernel and depend on my provider. i am quite sure, there are others around too.

2 1

[arch-general] Iinstallation program
by Jan Litwiński 27 Sep '12

27 Sep '12

When will Arch have more friendly installation program like Ubuntu, Fedora, or opwnSUSE. I installed Arch some years ago and it was very difficult for me. -- Jan Litwiński http://netsjanek.blogspot.com/ Linux is like a wigwam no gates no windows but apache inside

15 18

[arch-general] The future of sysvinit in Arch: Call for Help
by Tom Gundersen 27 Sep '12

27 Sep '12

Hi guys, As the move to systemd is under way, and we will soon have packages in our repos that require your system to be booted with systemd, I thought this would be a good time to summarize the state of sysvinit/initscripts in Arch and their future. Abstract: I think the current state is relatively good (but I'm clearly very biased) and it should not be hard to maintain a non-systemd boot on Arch even in the long-run. However, someone has to do the work. NOTE: Please let's keep any replies on-topic. This is NOT about whether or not sysvinit or systemd is good or bad. Testing ===== This has been repeated a lot, but I think it makes sense to say it again: We are quickly running out of people who do early testing of initscripts. I.e., who follow arch-projects, review patches and test initscripts-git. At some point we will probably also struggle with a lack of developers/TU's testing initscripts in [testing], so if you feel passionately about a non-systemd boot on Arch, please join arch-projects and help with testing. Initscripts ====== Initscripts are currently fully supported and actively developed. Work has been going on for a long time to make initscripts and systemd share the same configuration file format wherever that makes sense, and this work is mostly completed (at least on the initscripts side). Moreover, code is shared between systemd and initscripts wherever possible (there might still be more opportunities for this, but the work is mostly completed). Together, these two developments should make it relatively easy to maintain initscripts for Arch in the long-run, even with a small user/developer base. I intend to maintain initscripts in the official repos as long as this makes sense. However, for this to be viable, I think we would need at least one capable and active initscripts developer who is interested in helping out and who uses sysvinit/initscripts as their main init system. In the long-run it would make sense for such a person to take over maintainership of initscripts. Anyone interested, please join arch-projects and post reviews, suggestions and patches :-) Packages requiring systemd ================= In the (near) future, we expect some packages to no longer support non-systemd boot. In particular I'm thinking of polkit, networkmanager and some gnome packages (I don't know which as I don't use gnome myself). There will probably be more in the future. We might also drop ConsoleKit from the repos at some point in the future. No need to panic though. The number of packages that will actually be need to be rebuilt to support non-systemd boot are actually very limited (certainly less than ten). An alternative repository just providing the relevant packages could very easily be maintained by one committed person (possibly even the same person that will help out with initscripts). I would be happy to help with getting this started if anyone is interested. A point to keep in mind is that the people who don't want to switch to systemd, might not be using ConsoleKit, polkit, etc anyway, so maybe this problem is not actually a real one. rc scripts ===== Currently we have a few hundred rc scripts in our repos (the scripts under /etc/rc.d/) shipped with our various packages. This will probably not change in the near future, but if for whatever reason some packagers decide to drop some rc scripts from their packages (and rely purely on the systemd unit files), then it would be very simple to pull the relevant scripts from our repos and ship them in a rc-scripts package in the above suggested repository. Concluding remarks ============ As I have tried to outline above, the amount of work required for a non-systemd boot is really small, and I'd be happy to help anyone who decides to take it on. However, I have seen some suggestions of ways of avoiding systemd that entails splitting the systemd package up, rebuilding tens of packages just to avoid a systemd-libs dependency or re-duplicate all the code shared between initscripts and systemd. This, in my humble opinion, is not worth the effort and is not something I'd be interested in getting involved with. Please direct any technical discussions to arch-projects(a)archlinux.org. Cheers, Tom

3 4

[arch-general] Laptop auto shudown
by 大熊 27 Sep '12

27 Sep '12

I have a fresh installed laptop, DE is lxde. It is a clean system, no more tweak. Recently I found a strange problem: after I close the lid about 5 minutes, laptop will shutdown itself! I donot remeber I have do some setting about power management, and I have installed pm-utils, but not acpid. Is it a default feature of archlinux on laptop? -- 立志在女儿把我搞崩溃前把她养大看着女儿一天天长大，可惜我还是菜鸟

3 3