Hi,

Found this :

/sbin/ldconfig: libraries libidn.so.11.6.8 and libidn.so.11.6.13 in directory /usr/lib have same soname but different type.

$ grep libidn.so. /var/log/packages/*
/var/log/packages/aaa_elflibs-14.1-arm-6:usr/lib/libidn.so.11.6.8
/var/log/packages/libidn-1.30-arm-1:usr/lib/libidn.so.11.6.13

Dunno it that's why, but libidn have been upgraded today in Slackwarearm but not in Slackware x86.

Anyway the error could mean that there are two symlinks pointing to the same library but their version numbers appear differently.

I can't check because I don't have Slackwarearm, but "ls -alh /usr/lib/libidn*" could confirm that.

As a side note, it is not uncommon that aaa_elflibs ships older version of shared libraries than other packages, about that check this thread, not surprisingly started by Stuart who also is Slackwarearm's maintainer, as you know

root@darkstar:~# ls -alh /usr/lib/libidn*
-rw-r--r-- 1 root root 216K Apr 30 06:15 /usr/lib/libidn.a
-rwxr-xr-x 1 root root 928 Apr 30 06:15 /usr/lib/libidn.la*
lrwxrwxrwx 1 root root 17 Apr 30 20:27 /usr/lib/libidn.so -> libidn.so.11.6.13*
lrwxrwxrwx 1 root root 17 Apr 30o.11 -> libidn.so.11.6.13*
-rwxr-xr-x 1 root root 192K Apr 30 06:15 /usr/lib/libidn.so.11.6.13*
-rwxr-xr-x 1 root root 192K Jun 25 2012 /usr/lib/libidn.so.11.6.8*
-rwxr-xr-x 1 root root 637 Aug 8 2012 /usr/lib/libidnkit.la*
lrwxrwxrwx 1 root root 18 Apr 30 16:38 /usr/lib/libidnkit.so -> libidnkit.so.1.0.2*
lrwxrwxrwx 1 root root 18 Apr 30 16:38 /usr/lib/libidnkit.so.1 -> libidnkit.so.1.0.2*
-rwxr-xr-x 1 root root 207K Aug 8 2012 /usr/lib/libidnkit.so.1.0.2*
-rwxr-xr-x 1 root/usr/lib/libidnkitlite.la*
lrwxrwxrwx 1 root root 22 Apr kitlite.so -> libidnkitlite.so.1.0.2*
lrwxrwxrwx 1 root root 22 Apr 30 16:38 /usr/lib/libidnkitlite.so.1 -> libidnkitlitet root 203K Aug 8 2012 /usr/lib/libidnkitlite.so.1.0.2*

The libidn update was premature, but the warning is harmless: the old library is no longer required and has been removed from the elflibs package for the next update batch.

Ok, thanks.

rc.sshd echoes "SSH key generation: This will take a few minutes on older hardware" even if keys has already been generated.
It's a bit annoying :/ .

Yes I noticed this a while ago and wondered if it was a bug - it's not.
The message is no longer required though - on the RiscPC (where ARMedslack was originally developed), generating SSH keys almost a minute or more, where as now it only takes a couple of seconds.

I've rebuilt openssh without that message.

I noticed that /etc/rc.d/rc.inet1 sometimes doesn't get an IP address, I have to restart it manually.
I have the same exact behaviour with Slackware64 -current.

I had this issue on the Banana Pi. The ARM current push today changes the default timeout from 10 seconds to 12 seconds.
If your machine is constantly tethered to an Ethernet cable, you might want to set the timeout to 0 seconds so that dhcpcd will wait until it receives an IP before backgrounding. This has the effect that your bootup will stall until you get an IP. For me this is a good thing.

Ok, thanks.

xf86-video-fbturbo is reported speeding up things on ARM :
https://github.com/ssvb/xf86-video-fbturbo

Do you have hardware that you can use to test it? I can build it and see if it works before switching them.

I didn't properly benchmark, but performance seems the same on my board.
The driver compiles and runs, libUMP is an optional dependency https://github.com/linux-sunxi/libump .

It's reported to smooth things on the future Pyra (Open Pandora 2).
http://boards.openpandora.org/topic/...rivers-status/

So on the same hardware :

Debian with fbturbo : X at 0% cpu usage when idle, not much when moving windows, very fluid
Debian without fbturbo : X at 0% cpu usage when idle, much when moving windows, not fluid at all

Slackware-current with or without fbturbo : Xorg.bin at 20% cpu usage when idle, fluid

I'll do some tests on 14.1 later.

Attached Files

	Xorg.0.debian.log (25.6 KB, 23 views)
	Xorg.0.slack.log (26.1 KB, 18 views)

Slackware-14.1 with or without fbturbo : Xorg.bin at 0% cpu usage when idle, fluid.

How can I debug the 20% cpu usage on -current ?