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.
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?
That would be my understanding.
Thanks. I totally missed that.
There doesn't seem to be any variables cleared or set in slackpkg for LC_ALL or LC_COLLATE like in pkgtools and {remove,install}pkg, so I can now understand why this would be a problem when using different locales.
So, pkgtools, removepkg, and installpkg all seem to work fine with different locales, however, slackpkg can be affected if LC_COLLATE or LC_ALL is set to something other than C.
This is still a far cry from Rinndalir saying that there's a bug with SBo's package naming. Package naming is fine, it's just slackpkg doesn't always work properly if the locales are changed.
There doesn't seem to be any variables cleared or set in slackpkg for LC_ALL or LC_COLLATE like in pkgtools and {remove,install}pkg, so I can now understand why this would be a problem when using different locales.
So, pkgtools, removepkg, and installpkg all seem to work fine with different locales, however, slackpkg can be affected if LC_COLLATE or LC_ALL is set to something other than C.
Yes. The patch below fixes the issues (see the note #2 in coreutils manual) :
Code:
--- slackpkg.org 2016-09-19 11:50:42.646458844 +0200
+++ slackpkg 2016-09-19 11:50:28.607457496 +0200
@@ -23,6 +23,14 @@
#
+# unset LC_COLLATE and LANG, then set LC_ALL to C to prevent potential
+# issues when sorting data. For more about this read :
+# gnu.org/software/coreutils/manual/coreutils.html#FOOT2
+#
+unset LC_COLLATE LANG
+export LC_ALL=C
+
+
#========================================================================
#
# LOAD CONFIGURATIONS
Original slackpkg :
Code:
$ LC_ALL=fr_FR.UTF-8 LC_COLLATE=en_US.UTF-8 slackpkg -dialog=off -default_answer=no -batch=on upgrade-all
Checking local integrity... DONE
Looking for packages to upgrade. Please wait... comm: le fichier*2 n'est pas dans l'ordre attendu
DONE
No packages match the pattern for upgrade. Try:
/usr/sbin/slackpkg install|reinstall
Patched slackpkg :
Code:
$ LC_ALL=fr_FR.UTF-8 LC_COLLATE=en_US.UTF-8 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-19-2016 at 05:06 AM.
Well, I doubt that many people manually set LC_CTYPE and anyway I am not in favor of setting LC_ALL as according to POSIX its value "has precedence over any of the other environment variables starting with LC_ (LC_COLLATE,LC_CTYPE,LC_MESSAGES,LC_MONETARY,LC_NUMERIC,LC_TIME) and the LANG environment variable." according to the § 8.2 Internationalization Variables of the POSIX specification: this is a little too much in my opinion.
Thus I suggest to set only LC_COLLATE and LC_CTYPE to C instead of LC_ALL.
Well, I doubt that many people manually set LC_CTYPE and anyway I am not in favor of setting LC_ALL as according to POSIX its value "has precedence over any of the other environment variables starting with LC_ (LC_COLLATE,LC_CTYPE,LC_MESSAGES,LC_MONETARY,LC_NUMERIC,LC_TIME) and the LANG environment variable." according to the § 8.2 Internationalization Variables of the POSIX specification: this is a little too much in my opinion.
Thus I suggest to set only LC_COLLATE and LC_CTYPE to C instead of LC_ALL.
But, if the user switched their LC_ALL to en_US (the only one I know off the top of my head), it would override LC_COLLATE and LC_CTYPE in the script and the script would still have its issues.
pkgtools and installpkg both just unset all the LC_ variables and exports LANG as C, where removepkg exports LC_ALL to C. I'm not sure if one method is better than the other in these matters.
But, if the user switched their LC_ALL to en_US (the only one I know off the top of my head), it would override LC_COLLATE and LC_CTYPE in the script and the script would still have its issues.
Valid point.
Quote:
pkgtools and installpkg both just unset all the LC_ variables and exports LANG as C, where removepkg exports LC_ALL to C. I'm not sure if one method is better than the other in these matters.
The reason for the difference is that removepkg calls sort, which runs faster with LC_COLLATE set to C, IIRC.
In all cases it suffice to unset LC_ALL (as LC_CTYPE takes precedence over LANG), then export LC_COLLATE and LC_CTYPE set to C (or to POSIX), I think. Thoughts?
Last edited by Didier Spaier; 09-19-2016 at 07:33 AM.
But, if the user switched their LC_ALL to en_US (the only one I know off the top of my head), it would override LC_COLLATE and LC_CTYPE in the script and the script would still have its issues.
Valid point. I fail to see any good reason for an end user to set LC_ALL, but we can't prevent that anyway.
Quote:
pkgtools and installpkg both just unset all the LC_ variables and exports LANG as C, where removepkg exports LC_ALL to C. I'm not sure if one method is better than the other in these matters.
The reason for the difference is that removepkg calls sort, which runs faster with LC_COLLATE set to C, IIRC.
In all cases it suffice to unset LC_ALL, then export LC_COLLATE and LC_CTYPE, set to C (or to POSIX), I think. Thoughts?
PS Sorry for the duplicate post.
Last edited by Didier Spaier; 09-19-2016 at 07:39 AM.
Reason: PS added.
In all cases it suffice to unset LC_ALL, then export LC_COLLATE and LC_CTYPE, set to C (or to POSIX), I think. Thoughts?
Seeems to work well :
Code:
$ LC_ALL=fr_FR.UTF-8 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
$ LANG=en_US LC_ALL=fr_FR.UTF-8 LC_COLLATE=fr_FR.utf-8 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
Here is the patch :
Code:
--- slackpkg.org 2016-09-19 11:50:42.646458844 +0200
+++ slackpkg 2016-09-19 14:03:27.432223621 +0200
@@ -22,6 +22,13 @@
# Evaldo Gardenali (aka UdontKnow) evaldogardenali@fasternet.com.br
#
+# unset LC_ALL, then set LC_COLLATE and LC_CTYPE to C to prevent potential
+# issues when sorting data. For more about this read :
+# gnu.org/software/coreutils/manual/coreutils.html#FOOT2
+#
+unset LC_ALL
+export LC_COLLATE=C
+export LC_CTYPE=C
#========================================================================
#
--
SeB
Last edited by phenixia2003; 09-19-2016 at 07:43 AM.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,136
Rep:
Quote:
Originally Posted by leeeoooooo
Slashdot said today that there was a major new version of vim released!
Here you go:
Quote:
Thu Sep 15 22:54:52 UTC 2016
a/bash-4.4.0-x86_64-1.txz: Upgraded.
a/btrfs-progs-v4.7.2-x86_64-1.txz: Upgraded.
a/e2fsprogs-1.43.3-x86_64-1.txz: Upgraded.
a/pkgtools-14.2-noarch-12.txz: Rebuilt.
removepkg: Fixed removing packages with >= 3 hyphens in the package name
when using just the package name rather than the full name including
version, arch, and build.
Thanks to coralfang for the bug report, Jim Hawkins and Stuart Winter for
the patch, and SeB for testing and feedback.
removepkg: Handle filenames that contain backslashes.
Thanks to aaazen for the bug report and patch.
ap/vim-8.0.0005-x86_64-1.txz: Upgraded.
n/curl-7.50.3-x86_64-1.txz: Upgraded.
Fixed heap overflows in four libcurl functions: curl_escape(),
curl_easy_escape(), curl_unescape() and curl_easy_unescape().
For more information, see: https://curl.haxx.se/docs/adv_20160914.html http://cve.mitre.org/cgi-bin/cvename...=CVE-2016-7167
(* Security fix *)
xap/vim-gvim-8.0.0005-x86_64-1.txz: Upgraded.
+--------------------------+
Tue Sep 13 18:13:32 UTC 2016
ap/mariadb-10.0.27-x86_64-1.txz: Upgraded.
This update fixes a critical vulnerability which can allow local and
remote attackers to inject malicious settings into MySQL configuration
files (my.cnf). A successful exploitation could allow attackers to
execute arbitrary code with root privileges which would then allow them
to fully compromise the server.
This issue was discovered and reported by Dawid Golunski.
For more information, see: http://legalhackers.com/advisories/M...2016-6662.html https://jira.mariadb.org/browse/MDEV-10465 http://cve.mitre.org/cgi-bin/cvename...=CVE-2016-6662
(* Security fix *)
ap/vim-8.0.0003-x86_64-1.txz: Upgraded.
xap/vim-gvim-8.0.0003-x86_64-1.txz: Upgraded.
I've built it here and tested on this page and it seems to work fine: it downloads and installs an additional plugin, Google Widevine Content Decryption Module.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,136
Rep:
Quote:
Originally Posted by ponce
I've built it here and tested on this page and it seems to work fine: it downloads and installs an additional plugin, Google Widevine Content Decryption Module.
The page linked above does work, but Netflix does not. It keeps asking for the microsoft silverlight plugin.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
