SlackwareThis Forum is for the discussion of Slackware Linux.
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.
I see support in the kernel for Caicos (HD6450), have you tried the KMS driver? I think that even AMD are dropping all support for proprietary linux drivers on all GPUs.
I think you need to learn what is in a SlackBuild script, and what is in the source folder. That line is only contained in the net-tools.url file within the source folder for net-tools, but it is not part of the SlackBuild and it is never run. As I said in the other thread, this is likely there as a reference for how Pat got the source for the version that is used.
Broken arp. I don't have arp anymore, I've removed the package. While looking for a solution I found that many distros using net-tools have not pulled recently and are relying on some official release to come.
They are using the net-tools-1.60.20120726git.tar
Meant to add that it doesn't seem like the project's going to do a release. Looks like more of a rolling release style. i.e git pull
Seems like an SBo bug in their package naming. And why do they mix their package data in with slackware packages. Separate directories would be cleaner.
I think he means that your post makes no sense, even to people who speak/write English fluently (and Eric seems to have quite the mastery of the English language, so I certainly wouldn't think it is an issue with him not understanding English).
What "package data" is getting mixed with Slackware packages? Packages get installed to wherever the package maintainers specifies in the SlackBuild, which is generally under /usr/. Looking over both the packages' entries in /var/log/packages/, there doesn't seem to be any collisions other than a few similar folders (which is normal -- the majority of the packages will contain the same folders)... but removepkg doesn't remove any folders unless there is nothing left in them.
There is no bug with the naming. Pkgtools is able to distinguish between sqlite and sqlite2, so there should be no "SBo bug in their package naming".
So, if you truly think this is a problem, maybe you should provide a bit more information behind it so the powers that be can see what you're talking about, and if it truly is an issue, would be able to find a fix.
Broken arp. I don't have arp anymore, I've removed the package. While looking for a solution I found that many distros using net-tools have not pulled recently and are relying on some official release to come.
They are using the net-tools-1.60.20120726git.tar
What exactly is broken?
Code:
jbhansen@febtober:~$ arp
Address HWtype HWaddress Flags Mask Iface
reborn-therapist ether 48:5d:60:33:13:22 C eth0
craven-moorhead ether 40:8d:5c:76:e8:49 C eth0
10.0.0.144 ether 00:25:ae:77:71:4e C eth0
10.0.0.143 ether 00:09:b0:d4:98:e0 C eth0
DD-WRT ether 2c:30:33:51:3f:b3 C eth0
jbhansen@febtober:~$ sudo arp -d 10.0.0.143
jbhansen@febtober:~$ arp
Address HWtype HWaddress Flags Mask Iface
reborn-therapist ether 48:5d:60:33:13:22 C eth0
craven-moorhead ether 40:8d:5c:76:e8:49 C eth0
10.0.0.144 ether 00:25:ae:77:71:4e C eth0
10.0.0.143 (incomplete) eth0
DD-WRT ether 2c:30:33:51:3f:b3 C eth0
jbhansen@febtober:~$ ping 10.0.0.143
PING 10.0.0.143 (10.0.0.143) 56(84) bytes of data.
64 bytes from 10.0.0.143: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from 10.0.0.143: icmp_seq=2 ttl=64 time=0.437 ms
64 bytes from 10.0.0.143: icmp_seq=3 ttl=64 time=0.476 ms
^C
--- 10.0.0.143 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.437/0.450/0.476/0.025 ms
jbhansen@febtober:~$ arp
Address HWtype HWaddress Flags Mask Iface
reborn-therapist ether 48:5d:60:33:13:22 C eth0
craven-moorhead ether 40:8d:5c:76:e8:49 C eth0
10.0.0.144 ether 00:25:ae:77:71:4e C eth0
10.0.0.143 ether 00:09:b0:d4:98:e0 C eth0
DD-WRT ether 2c:30:33:51:3f:b3 C eth0
I don't know much about arp, but it seems to be working fine here... Be more specific about your bug reports other than to just say it's broken, otherwise, if you don't tell people, they won't have any reason to try and fix what they don't know is broke.
Broken arp. I don't have arp anymore, I've removed the package.
That would be correct, not having arp after removing the package. Well done.
Now, before you removed the package, arp would have been in /sbin/arp and it would have worked as usual. I tested it on Slackware 13.37 and 14.2.
Again, define "broken" in relation to the net-tools package that is part of Slackware and contains the arp binary.
There is no bug with the naming. Pkgtools is able to distinguish between sqlite and sqlite2, so there should be no "SBo bug in their package naming".
So, if you truly think this is a problem, maybe you should provide a bit more information behind it so the powers that be can see what you're talking about, and if it truly is an issue, would be able to find a fix.
The problem appears when the system has third-party packages (SBo, Alien...) with similar names but different versions (when the number is added to the package name: as in 'sqlite' and 'sqlite2-*SBo'.
These examples are typical for Slackware (for e.g. packages like 'db42', 'db44', 'db48') and in such cases everything works fine. But in case when there are third-party packages everything falls apart and the problem is not connected with package names.
There is no problem when LC_COLLATE is C, but with other values of "LC_COLLATE" (not English for e.g.) script 'slackpkg' receives alerts like "comm:.file 2 is not in sorted order" and the system does not work correctly.
The solution is just a small patch for sort file ${TMPDIR}/dpkg in function listpkgname() in core-functions.sh or set "LC_COLLATE=C" in system preferences, but not everybody should set LC_COLLATE=C obviously. Btw, this problem is there for a long time as you can read in this thread.
The solution is just a small patch for sort file ${TMPDIR}/dpkg in function listpkgname() in core-functions.sh or set "LC_COLLATE=C" in system preferences, but not everybody should set LC_COLLATE=C obviously. Btw, this problem is there for a long time as you can read in this thread.
You can also define an alias for slackpkg :
Code:
$ alias slackpkg="LC_COLLATE=C slackpkg"
$ locale|grep LC_COLLATE
LC_COLLATE=fr_FR.utf8
$ slackpkg -dialog=off -default_answer=no -batch=on upgrade-all
Checking local integrity... DONE
Looking for packages to upgrade. Please wait... DONE
sqlite-3.13.0-x86_64-1.txz
Total package(s): 1
Do you wish to upgrade selected packages (Y/n)? n
--
SeB
Last edited by phenixia2003; 09-17-2016 at 08:58 AM.
The problem appears when the system has third-party packages (SBo, Alien...) with similar names but different versions (when the number is added to the package name: as in 'sqlite' and 'sqlite2-*SBo'.
These examples are typical for Slackware (for e.g. packages like 'db42', 'db44', 'db48') and in such cases everything works fine. But in case when there are third-party packages everything falls apart and the problem is not connected with package names.
There is no problem when LC_COLLATE is C, but with other values of "LC_COLLATE" (not English for e.g.) script 'slackpkg' receives alerts like "comm:.file 2 is not in sorted order" and the system does not work correctly.
The solution is just a small patch for sort file ${TMPDIR}/dpkg in function listpkgname() in core-functions.sh or set "LC_COLLATE=C" in system preferences, but not everybody should set LC_COLLATE=C obviously. Btw, this problem is there for a long time as you can read in this thread.
This makes a lot more sense than Rinndalir's cryptic post. Thanks!
Looking further into this, it seems that pkgtool and installpkg both unset the LC_COLLATE variable when the script is run. But that is not in removepkg.
Code:
# Avoid problems if any files in /var/log/packages and /var/log/scripts
# might contain any broken UTF-8 sequences. This was once known to cause
# dialog to crash.
unset LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY \
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT \
LC_IDENTIFICATION LC_ALL
LANG=C
export LANG
# This makes "sort" run much faster:
export LC_ALL=C
I wonder if the default $LANG variable is causing the sort issues, as LANG can override LC_ALL. But, setting LC_COLLATE shouldn't cause any difference unless I'm reading things wrong. However, doing a quick check on my computer seems to show that $LANG does not affect sorting and LC_ALL overrides LC_COLLATE, so removepkg *should* function as it's supposed to.
Code:
jbhansen@craven-moorhead:~$ echo $LANG \| $LC_COLLATE \| $LC_ALL
en_US | C |
jbhansen@craven-moorhead:~$ sort <<< $'a\nb\nA\nB'
A
B
a
b
jbhansen@craven-moorhead:~$ LC_ALL=en_US sort <<< $'a\nb\nA\nB'
a
A
b
B
jbhansen@craven-moorhead:~$ LC_COLLATE=en_US sort <<< $'a\nb\nA\nB'
a
A
b
B
jbhansen@craven-moorhead:~$ LC_COLLATE=en_US LC_ALL=C sort <<< $'a\nb\nA\nB'
A
B
a
b
Maybe I don't have a deep enough understanding of locales, but based on my quick testing, I'm not seeing why removepkg should have a problem. I'd love some more insight on this, if anyone else is more familiar with it.
@Rinndalir, if you provided more information like th_r did with your "bug reports", people would be a lot more likely to take them seriously and look deeper into the issue.
Maybe they mean that slackpkg is affected. pkgtools might still work just fine, but maybe something internal to slackpkg is affected by the locale settings?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
