Arch 0.7.1 upgrade

I'm and old Slack user. Recently I installed (clean) arch 0.7.1 and I like it very much, however, I noticed that **every time** I exit KDE kicker crashes.
Since I did not notice that bebavior in arch 0.7 (my first test) nor it is a problem in any of my Slackware boxes (all running KDE 3.5.0) I concluded that it could be a corrupted KDE. To "fix" the problem I removed all KDE (pacman -Rd kde), but when I try to re-install (pacman -Sy kde) it fails with the message "kdebase-3.5.0-4.pkg.tar.gz is currpted" (!!?)
Any help would be appreciated. I love KDE and I really ( I mean REALLY!) like Arch.
Thanks,
Rick

I did the "kill the folder" thing but ... no such luck. The problem persists.
I went to KDE's web site and I can see that they duscuss the problem. It is also rated as SOLVED in some places of the site and (in the same site) depending on the output errors from kicker window as NOT VERIFIDED. ??!
I wonder if it is related to the way the packages are put together in each distro. I have NEVER had the problem in Slackware, and I have been running it as my sole OS for over 4 years. In fact in my office I have yet Slackware 10.2 (with KDE 3.5.0) and at home I was using it until last week when I "migrated" to Arch.
I love the speed of Arch and the package manager. This is the way things should be if Linux it to ever live outside the "geek space". ;-)
I know, I know, this is not the easiest distro for new users but I think things will evolve with time and Arch is sure moving in the right direction.
Thanks again.
Rick

Similar Messages

How does Arch cope with occasional upgrades?

Hi all,
I'm a long time Gentoo user, but as I don't have the time to upgrade my system every five minutes I only end up running upgrades every few months (or when I want to install a program that has a long string of dependencies.)
Unfortunately this process always ends in tears for me, as Gentoo is not designed to go for more than a few weeks between upgrades. So every time I do this packages fail to compile, programs won't run because of missing dependencies, libraries can't be upgraded because of weird conflicts, and I generally end up tearing my hair out trying to get my system back up and running again.
So I've pretty much had enough of this and I'm looking for a new distro. Gentoo would be perfect if it could cope with lengthy delays between upgrades, and from what I have read Arch has a similar methodology so I'm thinking Arch might be the way to go.
So - how does Arch cope if you wait six months or more between upgrading software packages? After upgrading a library, do you need to "manually" (at least Gentoo has a script) find applications that have broken and update those too? Or does pacman leave you with a working system every time you run it?
Any other insights that would be useful for someone coming from the Gentoo world?
Thanks!

Thanks for the helpful replies! Just to clarify, the problems I have with Gentoo are not so much the changes (e.g. updating configuration files to work with a new app version) my main complaint is that the upgrade just doesn't work. If I could run one command and come back 24 hours later and it was complete then that would be fine, the problem I have is that it breaks every few packages so doing a full upgrade takes days - and I mean days where you are sitting in front of it manually adding, removing and reinstalling packages to keep the package management system happy.
So when you mention things like packages changing their names or a python2 -> python3 transition, do you mean that pacman can't automatically handle this, and some manual intervention would be required? Because really, all I'm after is something like Gentoo but with less compile errors and nonsense complaints about package conflicts - something smart enough to just figure out what needs to be done by itself. But if this is likely to happen under Arch as well, maybe you're right and something like Ubuntu would be more my style (wow, coming from Slackware originally, I never thought I'd say that!)
Of course if it's binary-based then presumably these errors surface much faster than they do with Gentoo, so I'm curious - what are the types of problems you mostly get from pacman when upgrading your whole system?

OS X and Arch dual-boot on MBP - bootloader error

I have a Macbook Pro 9,2, and I dual-boot OS X and Arch. My main Arch partition is encrypted with an LVM on LUKS setup, and my main OS X partition is encrypted with Firevault 2. I run the vanilla Arch kernel, and I use xfce as my DE. I use refind as my boot manager, and grub as the bootloader for the Arch partition. This setup has worked flawlessly for several months. I update my Arch system once per week, and last Sunday was a large update since xfce got a large overhaul (in terms of program and config files). However, since the update I cannot boot into OS X (I am posting this here instead of an OS X forum since no change occurred to the OS X system so the problem must be with a change to my Arch system).
When I attempt to boot into OS X, I am asked for my password to decrypt the partition, but then I get the following error message:
efiboot loaded from device: Acpi (PNP0A03,0)/Pci(1F12)/SATA(0,0)/HD(Part3.Sig698A
48BA-88E6-471C-9359-AD63C7EEBE74
boot file path: \System\Library\CoreServices\boot.efi
............Read error 0x6
Error loading kernel cache (0x6)
Error: Aborted returned from boot.efi
*Hit any key to continue*
Starting boot.efi
Using load options ''
efiboot loaded from device: Acpi (PNP0A03,0)/Pci(1F12)/SATA(0,0)/HD(Part3.Sig698A
48BA-88E6-471C-9359-AD63C7EEBE74
boot file path: \com.apple.recovery.boot\boot.efi
.............Read error 0x6
Error loading kernel cache (0x6)
Error: Aborted returned from boot.efi
*Hit any key to continue*
When I hit a key, I get taken back to the refind menu. If I choose OS X again, I get the same error. This cycle can be repeated ad nauseam. Booting into my Arch partition, on the other hand, works just fine, with one hiccup. While usability does not seem to be reduced, after I input my password to decrypt the Arch partition, and before I see the tty1 login, I (since Sunday) occasionally get the following error message that I have never had before:
19.636262] [drm:crypt_set_fifo_underrun_reporting] *ERROR* uncleared pch fifo underrun on pch transcoder
19.636264] [drm:crypt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun
19.331860] ata1.00: exception Emask 0x50 SAct 0x1100 SErr 0x280900 action 0x6 frozen
19.331927] ata1.00: irq_stat 0x08000000, interface fatal error
19.331974] ata1: SError: {UnrecovData HostInt 10B8B BadCRC }
19.332821] ata1.00: failed command: READ FPDMA QUEUED
19.332866] ata1.00: cmd 60/00:40:70:c1:01/01:00:24:00:00/40 tag 8 ncq 131072 in
19.332866] res 40/00:60:b0:55:2a/00:00:24:00:00/40 Emask 0x50 (ATA bus error)
19.332176] ata1.00: status: { DRDY }
The "READ FPDMA QUEUED" line and those below it repeat a few time with different numbers following "cmd" and "res," but then after a few moments the messages clear off the screen and I arrive at my tty1 login screen and from there everything in Arch (including my now-upgraded DE) works normally. This error does not occur during all boots, but I cannot discern any pattern behind when I see it and when I do not. The OS X error and failure to boot occurs every time I try to boot into OS X.
I have learned a lot as an Arch user, but this problem is beyond me. Google has not been particularly friendly, understandably so given the peculiarity of the problem and my setup. I have not yet tried undoing the update I did on Sunday because (a) it would be a pain since there were >30 packages that were upgraded, and (b) I have no evidence that the upgrade was actually causative of this issue, though I may eventually attempt the downgrade out of desperation if I cannot find a solution. Note that the update I keep referencing did not including a kernel update.
I appreciate any advice or insight that you can offer.

I don't have much in the way of a solution for your problem, but to start with, what were the > 30 packages? In particular, was grub/refind updated (or anything else that would likely touch your efi partition? I know from my own messing with refind, that you can potentially 'damage' your partition layout with certain commands which maybe causing osx not to boot...
Then again, the errors may have nothing to do with your arch installation and maybe indicative of a different problem all together. Normal procedure is at this point is to backup your complete disk (clone/mirror it, read up on how to do that especially with regards to the encryption systems used), and try to diagnose for any problems the mbp maybe having.
You could use an apple rescue cd (that may no longer be available with newer mbp , I have no idea..) or maybe use a different harddisk and install osx there and see if you can get everything running 'normally' thus ruling out any funky errors with the hw. check apple's recovery options if need be.
I guess you'll just have to fiddle about a bit and try to more closely determine what the actual problem is. and again, backup your stuff!

Wlan problem after kernel upgrade

Hi,
after kernel upgrade to 2.6.25 I have to reinstall ndiswrapper for my wireless interface...
it's all right , I reinstalled :
usr5421x : driver installed
device (0BAF:011B) present (alternate driver: rndis_wlan)
but now, when I start system.... at network start (only wlan0) I have this error:
Jun 1 09:51:45 sacarde rndis_wlan 2-6:1.0: rndis media connect
Jun 1 09:51:46 sacarde dhcpcd[2643]: wlan0: dhcpcd 3.2.1 starting
Jun 1 09:51:46 sacarde rndis_wlan 2-6:1.0: rndis media disconnect
Jun 1 09:51:46 sacarde dhcpcd[2643]: wlan0: hardware address = 00:14:c1:1b:7f:43
Jun 1 09:51:46 sacarde dhcpcd[2643]: wlan0: broadcasting for a lease
Jun 1 09:52:16 sacarde dhcpcd[2643]: wlan0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-wlan0.info'
Jun 1 09:52:16 sacarde dhcpcd[2643]: wlan0: probing for an IPV4LL address
Jun 1 09:52:17 sacarde dhcpcd[2643]: wlan0: using IPV4LL address 169.254.59.172
Jun 1 09:52:17 sacarde dhcpcd[2643]: wlan0: adding IP address 169.254.59.172/16
Jun 1 09:52:17 sacarde dhcpcd[2643]: wlan0: exiting
and I have dhcp timeout
and network is down......
but now.... whenI just run:
iwconfig wlan0 ESSID *********
wlan0 go automaticaly UP, using right dhcp 192.168.1.* of lan
but with old kernel all was automaticly done....
in my rc.conf I have:
wlan0="dhcp"
wlan_wlan0="wlan0 essid *******"
WLAN_INTERFACES=(wlan0)
INTERFACES=(lo wlan0)
and load MODULES ndiswrapper
what happend ?
thankyou
Last edited by sacarde (2008-06-05 07:50:54)

sip03ds wrote:
Hello to all,
I have just upgraded to the latest kernel release:
#uname -r
2.6.30-ARCH
and after the upgrade, eth0 is unable to get IP from the DHCP server.
Thanks in advance!
Did you update dhcpd ? Is the module in the kernel or installed seperate ? Did you try to revert back to the previous kernel ?

[SOLVED] Boot problems after system upgrade

hi everybody,
first of all i have to say, that the machine where i installed Arch is pretty old (something around 5 years).
I already tried installing Arch two times and every time after i performed a system upgrade, i couldn't boot arch.
Before the upgrade i rebooted several times to ensure that its working with the brand new installation - it worked.
Here i'm the 3rd try. This time i configured packman to ignore the kernel package and voila its working now with kernel 2.6.25.6-1.
So, here is my question: Is there any problem that could appear later on if i never upgrade the kernel?
I'm quite new to linux and really appreciate your support.
Regards
Daniel
Last edited by mrorange (2010-02-25 21:35:32)

Well ... the kernel, like any other piece of program, from time to time has to be patched if they find a bug in it.
Never upgrading means that you do not get the benefit of security and improvements patches.
There is also the issue that some programs, a few, may want to have a certain kernel to run but I think that is less common.
I, for instance, have not upgraded the kernel for a few months now because it screws up my wifi.
If you can live with that then you are OK.
R.

Won't boot after kernel upgrade

I installed Arch and attempted to upgrade the kernel. I had to remove these pkgs because the depended on previous kernel:
ipw3945
madwifi
ndiswrapper
rt2500
tiacx
After kernel upgrade, won't boot:
Root device '....' doesn't exist, attempting to create it.
ERROR: Failed to parse block device name for '....'
ERROR: unable to create/detect root device '.......'
Dropping to recovery shell...
This is the final error messages after making the following attempts to correct the problem:
Added rootfstype=ext3 to kernel line.
Added rootdelay=8 (then 20) t6o kernel line.
Replaced UUID moniker with /dev/sda1 (SATA drive).
Checked /dev/ in recovery shell, no HD's listed.
Checked /etc/mkinitcpio.conf and it has sata listed under HOOKS.
Bill

userlander wrote:did you try the fallback kernel?
Yes, same result as with the upgraded kernel.

Terminal resolution breaks X11 after upgrades

I installed Arch Linux. I Upgraded the system with "pacman -Syu" and I installed X "pacman -S xorg".
Well, I started X before rebooting. All was working fine, I got three Xterm managed by the TWM.
After rebooting, I noticed the console resolution changed. The font became small. This happened while INIT was booting.
Well, now I cannot start X. I get a blank screen, and the PC crashes.
I have a Nvidia graphic card. Maybe the updates installed a framebuffer? can anyone help?
To get X11 working, I must remove or change the framebuffer.
I tried editing the kernel command line in GRUB, but it doesn't work.
I have a question: how can I disable the framebuffer loaded by udev?
Thanks for any reply.
Last edited by mghis (2010-12-08 15:46:32)

I think I'm using the nouveau driver. In fact it is in the output of "lsmod".
in fact, in the virtual terminal the resolution is fine, but if I start X i get a blank screen. Before the update, the resolution was 640x480, but X was working fine.
I tried to add "vga=" to the kernel command line but it doesn't changes the resolution.
if this helps, in /etc/mkinitcpio.conf HOOKS line is:
HOOKS="base udev autodetect pata scsi sata filesystems"
I think I have to change something in the UDEV configuration. In fact, when init shows udev is starting, the resolution changes.

Arch trashes config files in /etc?

Hi everyone, I just installed Arch today in a virtual machine to get a feel for it (trying to get away from the grind of Gentoo), and ran into the first obstacle...
I installed joe with "pacman -S joe", then I edited /etc/joe/joerc. That's when it occurred to me to check how Arch handles config file upgrades, so I just reinstalled joe with the same command, and to my amazement, all modifications from /etc/joe/joerc were gone and there was no backup in sight. Pacman simply overwrote the files in /etc/joe.
I was perusing the Wiki while downloading the CD image and the information there suggested that Pacman would save a backup copy of the previous config file, instead of just blindly overwriting. So, am I doing anything wrong? Does it put the backups in some different directory? Or is this feature not yet implemented? I'm really stuck on this, any help would be really appreciated.
If it helps, the CD version I downloaded is Archlinux-i686-2007.05-Duke-Linuxtag2007.current.iso, also during installation I selected only the "base" package set, and after installation I pointed the "current" repository in /etc/pacman.conf to the CD, so I could try out package management without waiting for packages to download.
P.S. The forum registration form is a bit broken, when it checks if you are a bot by asking the name of the distribution, it refused the answer "Arch Linux" and called me a bot. I obviously got past it, but still, it should accept "Arch Linux" because that is the name on the main web page and in the titles of all sub pages.

Oh, I see. You are right, the backup files section is empty, thanks.
This presents few more questions:
1) In your experience, are the packages in Arch generally sloppy like this when it comes to handling config files, or was this just bad luck to have a rare bug in my first ever installed Arch package?
2) Isn't this kind of handling of config files fragile? It would really suck to be toiling all night over some complex config file, only to have your hard work blown away on next upgrade because the packager made a typo in the list of backup files.
3) Would it be better to have a global option somewhere to specify whole directory trees as protected user-edited config files, instead of each package trying (and sometimes failing, obviously) to specify everything? Can you specify whole of /etc/* with the NoUpgrade option you mentioned, instead of each file one by one?

Error while loading shared libraries: libreadline.so.5

I left pacman downloading nvidia drivers, and when I came back my father had reseted the computer.
Now, I don't know what might be the cause, but starting Arch gives me something like this just after INIT 3
/bin/bash: error while loading shared libraries: libreadline.so.5 ...
And so on. It doesn't goes anywhere from there.
What can I do? I have Fedora too and no problems on accesing Arch's partition.

Just upgrade readline and bash
EDIT: You can't boot? Should have upgraded it first before rebooting!
Insert Live Cd and mount the / at /mnt
and :
pacman -r /mnt Sy bash
Last edited by sHyLoCk (2009-07-25 04:45:56)

Out of memory with no swap causes disk activity

Can someone explain what exactly is being read/written from/to disk in this situation?
I have 2 GB of RAM and no swap partitions. Occasionally I'll forget how inefficient gwenview is at displaying very large images and accidentally double-click one. The entire system freezes; even alt+sysrq keystrokes are ineffective (and yes I do have them enabled).
For about 5 minutes, the system is locked up and the hard drive light is flickering. That scares me a bit, because with no swap, what could it possibly be doing for 5 straight minutes? I used to think it was synching before doing the OOM-killing, but there's no way a sync could take that long. Judging from the sound of the hard drive, it's hda (the drive / and all the other system partitions are on).
A few times after recovering from this I've run extensive data verification and never found any evidence of corruption, but I'd like to know for sure that the kernel isn't randomly deciding to use some filesystem as swap space.
In the mean time, I'm playing with disabling overcommit -- setting vm.overcommit_memory = 2 in /etc/sysctl.conf. That enforces a hard memory commit limit of swap size + overcommit_ratio * ram size (so I've read) -- and I've also read that the default overcommit_ratio is only 50%. What the bloody hell? It's almost like someone thinks swap is more important than RAM -- hell-llo, I have 2 GB of RAM so that I can get *away* from swap!
Anyway, I've set the ratio to 97% and so far things seem happy -- if I deliberately run out of memory, the process that did it always gets killed instantly and the system doesn't freeze up on OOM anymore."
Another thing -- in all my out of memory situations so far, VMWare has been running. I suppose it's possible that VMWare is the one doing the swappage; I'll have to investigate that further.
~Felix.

I think I've finally figured this out. It's a kernel bug -- I'm guessing that under normal circumstances, the "cached" column in the free command "doesn't count" towards how much memory the system thinks it's using. After all, it's just cached copies of stuff that should be elsewhere, and if you run out of memory, you can safely dump that, right? Unfortunately, /dev/shm is counted under cached rather than used memory (as I discovered in an earlier post).
So if I've got 500 MB of stuff in /dev/shm * (which is where I mount my /tmp), there's now 500MB of stuff in the "cached" column that really does count -- system reaches all RAM full, decides it needs to dump cache, and suddenly finds that the 500MB it thought it could use isn't usable. For some reason it takes about 5 minutes of hard drive thrashing (probably because it's already chucked all of the system libraries, etc. out of cached and needs to re-read them from disk every time) before something finally figures out that it really is out of memory and that that 500MB isn't letting go and invokes OOM-killer.
*: VMWare does this; it creates a 512MB file (the amount of RAM in my virtual machine) then hides it by keeping the file open and deleting it, so the inode's still there, but you can't see it and it makes the df command really perplexing... but that's another story.
I haven't had a chance to try this with a newer kernel (maybe they've fixed it now?); I'm still running 2.6.23-ARCH here. (pacman -Syu upgrades are a major production for me because I have lots of RAID arrays and things, and an nvidia graphics card, and I use gnucash which sometimes needs manual recompiling, and so on...)

XFCE - Shutdown and Reboot buttons greyed-out (SOLVED)

This issue cropped up for me a couple of weeks ago. Just sat down to try and find a solution. Followed several suggestions from several posts to no avail.
Finally discovered that the syntax for achieving this in "/etc/sudoers" has evidently changed.
This is what I got from the XFCE site: http://forum.xfce.org/viewtopic.php?pid=21331 and is very similar to what's in the Arch Wiki, https://wiki.archlinux.org/index.php/Al … o_Shutdown. So I had been using the following line in /etc/sudoers and it had been working:
%users mylaptopname=NOPASSWD: /usr/lib/xfce4/xfsm-shutdown-helper
At some point in an XFCE upgrade the path to "xfsm-shutdown-helper" changed to "/usr/lib/xfce4/session/xfsm-shutdown-helper"
I changed the path to "xfsm-shutdown-helper" but that didn't solve the problem.
Finally I tried this in /etc/sudoers:
%users ALL=(ALL) NOPASSWD: /sbin/shutdown -h now,/sbin/reboot
And all the usual options in the shutdown menu re-appeared.
Hope this helps someone.
(Edited to show the link to the the XFCE forums and the Wiki.)
Last edited by whatshisname (2011-11-25 16:09:31)

Replying to my own post because of what I've discovered since I first posted this.
Most importantly, the fix which I thought had fixed this problem didn't really work. I was snookered into thinking it had. But I've found another solution which appears to be working now, thus this post.
Here's what I've found.
I had no login/display manager on my laptop. I was auto-logging into my desktop with this setting in /etc/inittab:
x:5:once:/bin/su myusername -l -c '/usr/bin/startx >/dev/null 2>&1'
The snooker alluded to above was this: If I booted to a command line and issued "startx" to start XFCE, I would have the shutdown and reboot buttons available on the logout dialog.
But if I booted directly into the desktop, I didn't. It's taken me a while to figure out that this is what was going on.
Even though my old setup had worked for the almost 2 years I've been using Arch and XFCE, some upgrade somewhere in recent months prevented it from working any longer.
My final fix was to install a login manager, in my case, lxdm. And set it to auto log me into my desktop.
I now have the expected reboot and logout menus.
Hope this helps someone. This has been a bear to figure out.

How to rebuild glibc on older gcc & kernel?

My env (these are dummy package with STLinux's prebuild binaries)
binutils 2.18.50.0.8-43
gcc 4.2.4-76
gcc-libs 4.2.4-76
glibc 2.6.1-74
linux-api-headers 2.6.23.17-1
I'm using old kernel on sh4 CPU arch and want to upgrade to newest gcc. So, I changed the glibc's PKGBUILD as
# toolchain build order: linux-api-headers->glibc->binutils->gcc->binutils->glibc
# NOTE: valgrind requires rebuilt with each major glibc version
pkgname=glibc
pkgver=2.17
pkgrel=3
pkgdesc="GNU C Library"
arch=('i686' 'x86_64' 'sh4')
url="http://www.gnu.org/software/libc"
license=('GPL' 'LGPL')
groups=('base')
depends=('linux-api-headers' 'tzdata' 'filesystem')
makedepends=('gcc')
backup=(etc/gai.conf
etc/locale.gen
etc/nscd.conf)
options=('!strip')
install=glibc.install
source=(http://ftp.gnu.org/gnu/libc/${pkgname}-${pkgver}.tar.xz{,.sig}
glibc-2.17-sync-with-linux37.patch
nscd.service
nscd.tmpfiles
locale.gen.txt
locale-gen)
md5sums=('87bf675c8ee523ebda4803e8e1cec638'
'6db4d1661cf34282755dc90330465f6d'
'fb99380d94598cc76d793deebf630022'
'c1e07c0bec0fe89791bfd9d13fc85edf'
'bccbe5619e75cf1d97312ec3681c605c'
'07ac979b6ab5eeb778d55f041529d623'
'476e9113489f93b348b21e144b6a8fcf')
build() {
cd ${srcdir}/${pkgname}-${pkgver}
# combination of upstream commits 318cd0b, b540704 and fc1abbe
#patch -p1 -i ${srcdir}/glibc-2.17-sync-with-linux37.patch
cd ${srcdir}
mkdir -p glibc-build
cd glibc-build
if [[ ${CARCH} = "i686" ]]; then
# Hack to fix NPTL issues with Xen, only required on 32bit platforms
# TODO: make separate glibc-xen package for i686
export CFLAGS="${CFLAGS} -mno-tls-direct-seg-refs"
fi
echo "slibdir=/usr/lib" >> configparms
# remove hardening options from CFLAGS for building libraries
CFLAGS=${CFLAGS/-fstack-protector/}
CFLAGS=${CFLAGS/-D_FORTIFY_SOURCE=2/}
${srcdir}/${pkgname}-${pkgver}/configure --prefix=/usr \
--libdir=/usr/lib --libexecdir=/usr/lib \
--with-headers=/usr/include \
--with-bugurl=https://bugs.archlinux.org/ \
--enable-add-ons=nptl,libidn \
--enable-obsolete-rpc \
--enable-kernel=2.6.23 \
--enable-bind-now --disable-profile \
--enable-stackguard-randomization \
--disable-multi-arch
# build libraries with hardening disabled
echo "build-programs=no" >> configparms
make
# re-enable hardening for programs
sed -i "/build-programs=/s#no#yes#" configparms
echo "CC += -fstack-protector -D_FORTIFY_SOURCE=2" >> configparms
echo "CXX += -fstack-protector -D_FORTIFY_SOURCE=2" >> configparms
make
# remove harding in preparation to run test-suite
sed -i '2,4d' configparms
check() {
# bug to file - the linker commands need to be reordered
LDFLAGS=${LDFLAGS/--as-needed,/}
cd ${srcdir}/glibc-build
make check
package() {
cd ${srcdir}/glibc-build
install -dm755 ${pkgdir}/etc
touch ${pkgdir}/etc/ld.so.conf
make install_root=${pkgdir} install
rm -f ${pkgdir}/etc/ld.so.{cache,conf}
install -dm755 ${pkgdir}/usr/lib/{locale,systemd/system,tmpfiles.d}
install -m644 ${srcdir}/${pkgname}-${pkgver}/nscd/nscd.conf ${pkgdir}/etc/nscd.conf
install -m644 ${srcdir}/nscd.service ${pkgdir}/usr/lib/systemd/system
install -m644 ${srcdir}/nscd.tmpfiles ${pkgdir}/usr/lib/tmpfiles.d/nscd.conf
install -m644 ${srcdir}/${pkgname}-${pkgver}/posix/gai.conf ${pkgdir}/etc/gai.conf
install -m755 ${srcdir}/locale-gen ${pkgdir}/usr/bin
# temporary symlink
ln -s ../../sbin/ldconfig ${pkgdir}/usr/bin/ldconfig
# create /etc/locale.gen
install -m644 ${srcdir}/locale.gen.txt ${pkgdir}/etc/locale.gen
sed -e '1,3d' -e 's|/| |g' -e 's|\\| |g' -e 's|^|#|g' \
${srcdir}/glibc-${pkgver}/localedata/SUPPORTED >> ${pkgdir}/etc/locale.gen
# Do not strip the following files for improved debugging support
# ("improved" as in not breaking gdb and valgrind...):
# ld-${pkgver}.so
# libc-${pkgver}.so
# libpthread-${pkgver}.so
# libthread_db-1.0.so
cd $pkgdir
strip $STRIP_BINARIES sbin/{ldconfig,sln} \
usr/bin/{gencat,getconf,getent,iconv,locale,localedef} \
usr/bin/{makedb,pcprofiledump,pldd,rpcgen,sprof} \
usr/lib/getconf/* \
usr/sbin/{iconvconfig,nscd}
[[ $CARCH = "i686" ]] && strip $STRIP_BINARIES usr/bin/lddlibc4
strip $STRIP_STATIC usr/lib/*.a
strip $STRIP_SHARED usr/lib/{libanl,libBrokenLocale,libcidn,libcrypt}-*.so \
usr/lib/libnss_{compat,db,dns,files,hesiod,nis,nisplus}-*.so \
usr/lib/{libdl,libm,libnsl,libresolv,librt,libutil}-*.so \
usr/lib/{libmemusage,libpcprofile,libSegFault}.so \
usr/lib/{pt_chown,{audit,gconv}/*.so}
checking for autoconf... autoconf
checking whether autoconf works... no
configure: error:
*** These critical programs are missing or too old: as ld gcc
*** Check the INSTALL file for required versions.
==> ERROR: A failure occurred in build().
Aborting...

a *very* quick guide
you can change the details to suit your environment
# = run as root
$ = run as regular user
# pacman -S abs
# abs
$ mkdir -p ~/abs/core/glibc
$ cp -R /var/abs/core/glibc ~/abs/core/glibc
$ cd ~/abs/core/glibc
$ vi PKGBUILD
modify the --enable-kernel line so it reads 2.6.18
$ makepkg
# pacman -U <your new glibc package>.xv
You might also want to add glibc to the ignorepkg line in pacman.conf. That way, you'll just be notified when a new version is out and you can repeat all of this. You don't need to resync the entire abs tree though, the following command will do it for one package
# abs core/glibc
One other tip - make sure you have a copy of the regular glibc package before making any changes just to be safe
Last edited by oliver (2011-03-02 21:17:24)

Problems with Technisat SkyStar2

Hello Arch community,
since i upgraded my ram i have some trouble with my SkyStar2 dvb-s card.
I can't watch tv or radio over this card but with my old 1 gb kit i can it?
I can't really describe this problem. You must see it
Only i can say: It's looks like a "no signal" error.
System configuration:
AMD ATHLON64 X2 4000+
8 GB DDR2-RAM PC6400 (Team Elite, 4x 2 GB)
Technisat SkyStar2 DVB-S
Arch Linux (last update was today) x86_64
output from 'dmesg | grep b2c2':
b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully
b2c2_flexcop_pci 0000:02:09.0: PCI INT A -> Link[LNKB] -> GSI 17 (level, low) -> IRQ 17
b2c2-flexcop: MAC address = 00:d0:d7:0b:60:0b
b2c2-flexcop: i2c master_xfer failed
b2c2-flexcop: i2c master_xfer failed
b2c2-flexcop: found 'ST STV0299 DVB-S' .
b2c2-flexcop: initialization of 'Sky2PC/SkyStar 2 DVB-S' at the 'PCI' bus controlled by a 'FlexCopIIb' complete
output from 'dmesg | grep DVB':
DVB: registering new adapter (FlexCop Digital TV device)
b2c2-flexcop: found 'ST STV0299 DVB-S' .
DVB: registering frontend 0 (ST STV0299 DVB-S)...
b2c2-flexcop: initialization of 'Sky2PC/SkyStar 2 DVB-S' at the 'PCI' bus controlled by a 'FlexCopIIb' complete
If you need more information, write me
Sorry for my very bad english - i can read english text but writing english text is very bad
Greets,
Christian from Germany

i think this is kernel bug because i found a message in the mailing list from linuxtv.org.
Now i will patch the original Kernel from arch and recompile and test ist.
http://www.linuxtv.org/pipermail/linux- … 29989.html

Load Average unusually high since installing fonts

A few days ago I installed a lot of fonts (over 1k). I quickly realized this was a bad idea, and I've uninstalled them (or at least I think I have). However, the load average on my machine is consistently over 2.0, many times over 3.0.
To uninstall the fonts, I went into Font Book, selected all of the fonts, then chose Resolve Duplicates. Then I restarted the machine.
Any ideas how to reduce the load average?
Thanks!

nachof wrote:2.6.31-ARCH
You should probably upgrade to the newest kernel, xorg and the radeon driver. I'm sure a lot of bugs have been fixed since 2.6.31 (maybe this one).
Last edited by thestinger (2010-11-26 00:33:37)

Nmap 3.93

I've update the nmap PKGBUILD taken from Arch CVS. I upgrade previous version on my pc without problem. That's the code:
# $Id: PKGBUILD,v 1.38 2005/02/22 19:02:41 dorphell Exp $
# Maintainer: dorphell <[email protected]>
pkgname=nmap
pkgver=3.93
pkgrel=1
pkgdesc="A network exploration tool and security/port scanner"
url="http://www.insecure.org"
depends=('pcre' 'openssl')
makedepends=('gtk')
source=(http://download.insecure.org/nmap/dist/$pkgname-$pkgver.tgz)
md5sums=('9998b39f09b7ee066ae2952bd009e453')
build() {
cd $startdir/src/$pkgname-$pkgver
./configure --prefix=/usr
make || return 1
make prefix=$startdir/pkg/usr install
rm -rf $startdir/pkg/usr/share/gnome
I've not modified PKGBUILD version ( 1.38 ).

You should refrain from posting updated PKGBUILD for stuff already in the repo. Especially if only the pkgver has to be changed. It just clutters the forums.

Arch 0.7.1 upgrade

Similar Messages

Maybe you are looking for