- Arch-general - lists.archlinux.org

[arch-general] updating xorg packages and nvidia packages, now x doesn't start
by Jeffrey Lynn Parke Jr. 20 Dec '10

20 Dec '10

I did a big update on my main arch machine and rebooted, I can't start X anymore. I saw that xorg-xinit and xorg-xauth as well as the nvidia packages were upgraded. Startx gives me a blank screen and switching to the first login (ctrl-alt-F1) shows a never ending "No Protocol Specified" message which finally fails with "xinit: unable to connect to X server: Connection refused" and "Xauth: error in locking authority file /home/user/.Xauthority" I checked my Xorg.0.log file and I see this message listed: (II) NVIDIA(0): Setting mode "nvidia-auto-select" (II) NVIDIA(0): ACPI: > failed to connect to the ACPI event daemon; the daemon (II) NVIDIA(0): may > not be running or the "AcpidSocketPath" X (II) NVIDIA(0): configuration > option may not be set correctly. When the (II) NVIDIA(0): ACPI event daemon > is available, the NVIDIA X driver will (II) NVIDIA(0): try to use it to > receive ACPI event notifications. For (II) NVIDIA(0): details, please see > the "ConnectToAcpid" and (II) NVIDIA(0): "AcpidSocketPath" X configuration > options in Appendix B: X (II) NVIDIA(0): Config Options in the README what could be the problem here?

4 6

Re: [arch-general] [arch-dev-public] [signoff] reiserfsprogs-3.6.21-3
by Allan McRae 20 Dec '10

20 Dec '10

On 04/12/10 22:34, Allan McRae wrote: > Rebuild and tidy of old package. > > Signoff both, > Allan > Anyone. User signoffs are all good too.

2 1

Re: [arch-general] [arch-dev-public] [signoff] isdn4k-utils-3.2p1-6
by Allan McRae 20 Dec '10

20 Dec '10

On 04/12/10 22:33, Allan McRae wrote: > Rebuild and tidy-up of old package. Merged the separate build fixes for > gcc-3.3, gcc-3.4 and gcc-4.0 into one patch. > > Signoff both, > Accepting user signoffs here too. Allan

1 0

[arch-general] postfix/procmail unable to write to /var/spool/mail/$USER
by David C. Rankin 19 Dec '10

19 Dec '10

Guys, I'm stuck on mail setup with a procmail error saying it can't write to /var/spool/mail/$USER. It is a postfix error, but it is complaining about procmail. An example of the error is: Dec 18 19:10:37 localhost postfix/local[2104]: E238BE7E78: to=<david@mymailaddress>, relay=local, delay=1.2, delays=0.14/0.04/0/1, dsn=5.2.0, status=bounced (can't create user output file. Command output: procmail: Error while writing to "/var/spool/mail/david" ) I'm fairly certain it is a user permission problem, but I can't recall ever changing anything before on my other setups to get procmail working. In this current config, /etc/postfix/main.cf has: mailbox_command = /usr/bin/procmail -a "$EXTENSION" The permission for /var/spool/mail are the exact same I have on my x86_64 Arch server at home where procmail is working just fine: [19:27 phoenix:/var/spool/mail] # l total 386772 drwxrwxrwt 2 root root 4096 Dec 18 19:13 . drwxr-xr-x 8 root root 4096 Dec 18 16:54 .. -rw------- 1 david dcr 362640748 Dec 18 19:05 david <snip> Just as with that box, I moved the mail spool from the suse install to the new install, so I don't think that would be the issue here. Anybody have any idea why postfix/procmail can't write to /var/spool/mail? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

3 4

[arch-general] dhcpd fails to start when using TSIG key created with hmac-sha256 encryption
by David C. Rankin 18 Dec '10

18 Dec '10

Guys, I have run into a problem with the dhcpd daemon refusing to start when using the default hmac-sha256 algorithm for key encryption. A good description of the problem is here: http://www.pubbs.net/201009/dhcp/8256-cant-start-isc-dhcpd-420.html The bind documentation shows host key creation using: dnssec-keygen -a hmac-sha256 -b 128 -n HOST yoursite.com This results in the following host key: Kyoursite.com.+163+02215.key it contains yoursite. IN KEY 512 3 163 BV_the_key________DG/g== from which you create the key for use with bind and dhcp in the form key yoursite.com { algorithm hmac-sha256; secret "BV_the_key________DG/g=="; }; bind will start and run using the key, but dhcpd fails to start giving the following error: [15:54 phoenix:/etc] # dhcpd -f Internet Systems Consortium DHCP Server 4.2.0-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ ../../../lib/dns/dst_api.c:1023: REQUIRE(keyp != ((void *)0) && (((*keyp) != ((void *)0)) && (((const isc__magic_t *)(*keyp))->magic == ((('D') << 24 | ('S') << 16 | ('T') << 8 | ('K')))))) failed, back trace #0 0x81756de in ?? #1 0x8175837 in ?? #2 0x8151058 in ?? #3 0x80c331a in ?? #4 0x80a7150 in ?? #5 0x80aa6cf in ?? #6 0x805c59c in ?? #7 0x8061bda in ?? #8 0x8061e6b in ?? #9 0x80620fc in ?? #10 0x804beab in ?? #11 0xb75fbc76 in ?? #12 0x804a0d1 in ?? Aborted Simply regenerating the key with hmac-md5 to create a ..+157..key works (dnssec complains about hmac-md5 now for some reason): dnssec-keygen -a hmac-md5 -b 128 -n HOST yoursite.com and then using that key in dhcpd.conf works fine. Does anybody have any additional background on this problem? I'm always hesitant to use an older key version when apparently ISC want you to use sha256. But obviously I need to get dhpcd going and providing updates to bind. Are there better alternatives to hmac-md5? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

1 1

[arch-general] We want to help
by Tomás Acauan Schertel 18 Dec '10

18 Dec '10

The Brazilian Arch Linux Community wants to help Arch Linux project, working on bug reports and feature requests. As first task, we plan to help conclude the development of AUR version 2. We don't have lots of developers, but we really want to help. And maybe others join us on this effort. To accomplish this, we need to enlighten some points: 1 - where should we look for feature requests? * bugs.archlinux.org? * AUR2 wiki page? 2 - what code repository should we take as start point? * git://gitorious.org/aur2/aur2.git -- the "central" repository with the stable branch * git://github.com/sebnow/aur2.git -- Xilon's repository * git://ius.student.utwente.nl/aur2 -- Thralas's repository * git://git.berlios.de/aur2 -- Djszapi's repository * git://github.com/SpeedVin/aur2.git -- SpeedVin's AUR2 forked repo with some patches and translation's. 3 - How Feature Requests / Bug Reports will be closed on flyspray? * Maybe a TU can do the job. Maybe things get easier if just one (maybe two) TU`s leads us on work. -- Tomás A. Schertel ---------------------------------------------- Linux Registered User #304838 Arch Linux User http://www.archlinux-br.org/ ----------------------------------------------

10 16

[arch-general] plans for Xorg/Mesa - closed drivers may break for some time in testing
by Andreas Radke 17 Dec '10

17 Dec '10

A new libdrm has been released. This is required to build new ddx drivers for nouveau and the latest intel rc driver for sandy bridge gfx. The current Mesa 7.9 branch won't build anymore the nouveau-dri stuff with the updated libdrm and it's quiet a buggy upstream release. Mesa 7.10 branch is short before the release and has tons of fixes and completes some missing features. We also have a minor Xorg-server 1.9.3 update pending that I will do in extra. Then there's already Xorg-server 1.10 rc1 out for some time we need to test. My plan is to start bringing new libdrm/mesa7.10/Xorg1.10 in the next days to testing. This will improve (me prays) the situation for open source drivers but will probably break the proprietary drivers for some time. I don't follow the closed stuff. Maybe you know something about the state of catalyst and nvidia with new Xorg 1.10. -Andy

2 1

[arch-general] howto tease and install of kdemod3 from the old packages?
by David C. Rankin 17 Dec '10

17 Dec '10

Guys, I know kdemod3 is considered dead, but I would like to install it on the new box I am setting up tonight. I have the full chakra repo of files and I thought it would be as simple as just creating an entry in pacman.conf to point to my server and the install would proceed. But I ran into an issue with [00:19 phoenix:~] # pacman -Sy kdemod3-complete :: Synchronizing package databases... core is up to date extra is up to date community is up to date archlinuxfr is up to date kdemod-legacy is up to date xyne-any is up to date resolving dependencies... warning: cannot resolve "libxxf86misc", a dependency of "kdemod3-kdebase" <snip 50 of the same> :: the following package(s) cannot be upgraded due to unresolvable dependencies: kdemod3-applets kdemod3-baghira-sidebar kdemod3-kdeaddons-base <snip the rest of the kdemod3 packages> Do you want to skip the above package(s) for this upgrade? [y/N] Yes, I know kdemod3 is broken by the cups strlcpy problem, but I use many of the kde3 apps in whatever desktop I use. For this new box it will most likely be just fluxbox, but I need kwrite, kate, konqueror, kcolorchooser, ksnapshot, quanta+, etc.... I hate the sloppy kde4 versions or it would load those. Before the kdemod-legacy repo was pulled, install was simple, so I wonder if it is possible to trick the installer into resolving "libxxf86misc" somehow so that the install can proceed. Anybody have any thoughts on how this can be done? Worst case, I guess I could cannibalize a kdemod3 install from one of my other boxes, but I would like to find a way to do a proper install since I have 3 more boxes to install. So, what says the brain trust? Possible? Not Possible? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

2 2

[arch-general] dmraid install failure (new thread)
by David C. Rankin 16 Dec '10

16 Dec '10

Sorry for the new thread, but I'm at the office and the 'leave message of server' in Tbird didn't work :( Sir Thomas wrote: >Am 16.12.2010 03:30, schrieb David C. Rankin: >> > Waiting 10 seconds for device /dev/mapper/nvidia_haheegdbp6 ... >> > >> > Root device '/dev/mapper/nvidia_haheegdbp6' doesn't exist. Attempting to >create it. >> > >> > ERROR: Unable to determine major/minor number of root device >> > '/dev/mapper/nvidia_haheegdbp6' >> > >> > You are being dropped to a recovery shell >> > >> > Type 'exit' to try and continue booting >> > >> > /bin/sh: can't access tty; job control turned off >> > >> > [ ramfs \ ]# >You have an almost fully functional system in that ramfs environment. >Look at the output of 'ls -l /dev/mapper' to see if the devices are >indeed missing. > Yep, but the issue is I haven't the foggies about what I can and can't do with the ramfs prompt. However, I think I have some additional information that will help. >Look at 'ls -l /dev/sd*' to see if your hard drives even show up. If >they do, try to issue 'dmraid -ay' again and see if the /dev/mapper >devices show up now. > All of the drives are there and you can see them with cat /proc/partitions. I tried recreating the arrays with 'dmraid -ay' but 'dmraid' isn't found. So it looks like it either wasn't installed (hard to believe because I install just about everything exept firmware stuff in the initial package selectioni), or for some reason the initramfs was made to include them. My guess is that it wasn't installed to begin with because dmraid should be there if it was. I'll go back and chroot the environment and see what happened to dmraid and report back. I'll bet that fixes it. Then the question becomes "Why wasn't dmraid installed to begin with?" Only 2 possible answers: (1) stupidity (never ruled out); or (2) a bug. I'll let you know. Thanks for your help. >This might just be a timing problem: dmraid -ay might be called before >/dev/sd* is fully set up and detected - we had these problems in the >past already. The 'sleep' hook put after the udev hook can work around that. > I>f it isn't a timing problem, then your hard drives are probably not d>etected. The reasons for this can be manifold, but it never hurts to >try if the fallback image shows the same behaviour. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

1 1

[arch-general] [PATCH]: suggestion for new udev.install
by Tom Gundersen 16 Dec '10

16 Dec '10

Hi UDev maintainers, Attached is a suggestion for a new udev.install file. Two changes: Removed the output regarding upgrading from udev =< 100. This is more than four years old, and was referring to a non-existent readme file. Added a conditional database conversion, as this is recommended when upgrading from udev <=164 to 165 (which was recently released). Cheers, Tom

2 2