Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
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.
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 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 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.
Code:
sed -i 's?\${DHCP_TIMEOUT\[\$i\]:-10\}?\$\{DHCP_TIMEOUT\[\$i\]:-0\}?g' /etc/rc.d/rc.inet1
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 .
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.