LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 12-20-2019, 09:02 PM   #4141
hpfeil
Member
 
Registered: Nov 2010
Location: Tucson, Arizona US
Distribution: Slackware Current
Posts: 285
Blog Entries: 1

Rep: Reputation: Disabled
Openssl


I noticed n/openssl10-1.0.2u-x86_64-1.txz among the current updates. Which packages still require that? Openssl.org suggests "All users of 1.0.2 are encouraged to upgrade to 1.1.1 as soon as possible." In less than a fortnight, 1.0.2 will no longer be supported. Is there a compelling reason to continue carrying v1.0.2?
 
1 members found this post helpful.
Old 12-21-2019, 05:44 AM   #4142
willysr
Senior Member
 
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 4,375

Rep: Reputation: 1558Reputation: 1558Reputation: 1558Reputation: 1558Reputation: 1558Reputation: 1558Reputation: 1558Reputation: 1558Reputation: 1558Reputation: 1558Reputation: 1558
it's to support some packages that still doesn't support OpenSSL 1.1.x.
 
2 members found this post helpful.
Old 12-21-2019, 12:11 PM   #4143
IlyaK
Member
 
Registered: Jun 2017
Location: Northwest Russia
Distribution: Slackware 14.2
Posts: 116

Rep: Reputation: 72
It would be nice to have p7zip. It is very popular, preinstalled on Windows10, an there is a slackbuild for it already.
Other slackbuilds depend on it, because people distribute their software packed with 7zip
 
2 members found this post helpful.
Old 12-21-2019, 12:30 PM   #4144
teoberi
Member
 
Registered: Jan 2018
Location: Romania
Distribution: Slackware64-current (servers)/Ubuntu (workstations)
Posts: 333

Rep: Reputation: 189Reputation: 189
p7zip is unmaintained software, the latest version is 16.02 (2016) and requires a few security patches.
I used as a source:
http://www.slackware.com/~alien/slackbuilds/p7zip/
but it does not contain all the patches.
 
1 members found this post helpful.
Old 12-21-2019, 12:36 PM   #4145
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware
Posts: 1,893

Rep: Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157
Perhaps add a way to mount /tmp to tmpfs? Minimally this could be done by adding the following to /etc/fstab:

Code:
# Uncomment the following to mount /tmp to tmpfs.
# tmpfs /tmp tmpfs defaults,noatime 0 0
A different method would be more elegant. Possibly /etc/rc.d/rc.tmpfs?

Similary, perhaps consider sym linking /var/run to /run. I've been doing this for years with no ill effects. The systems I support at work do likewise and nothing ill happens.
 
1 members found this post helpful.
Old 12-21-2019, 01:22 PM   #4146
ZhaoLin1457
Member
 
Registered: Jan 2018
Posts: 721

Rep: Reputation: 820Reputation: 820Reputation: 820Reputation: 820Reputation: 820Reputation: 820Reputation: 820
Quote:
Originally Posted by upnort View Post
Perhaps add a way to mount /tmp to tmpfs? Minimally this could be done by adding the following to /etc/fstab:

Code:
# Uncomment the following to mount /tmp to tmpfs.
# tmpfs /tmp tmpfs defaults,noatime 0 0
A different method would be more elegant. Possibly /etc/rc.d/rc.tmpfs?

Similary, perhaps consider sym linking /var/run to /run. I've been doing this for years with no ill effects. The systems I support at work do likewise and nothing ill happens.
This may be a nice solution for servers or workstations, but it may create strange and huge issues on home usage.

For example, when you burn a 4,7G DVD with the files from a directory, the K3b will create a 4,7G ISO file on /tmp , then it will fail if you have "only" 1GB or 2 GB of tmpfs. Also caching on /tmp do even the Midnight Commander, when you use whatever virtual filesystem for copying files to a remote location. So, it will fail mysteriously if you try to copy the slackware-current tree to a remote location.

Long story short, I believe that the /tmp on RAM is a terrible idea to have as default.

Last edited by ZhaoLin1457; 12-21-2019 at 04:07 PM.
 
2 members found this post helpful.
Old 12-21-2019, 01:39 PM   #4147
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware
Posts: 1,893

Rep: Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157
Point taken, but I mentioned nothing about being the default. The fstab suggestion is commented. By default the rc.tmpfs suggestion can be chmod -x. Both approaches could contain warnings about exceeding the capacity of actual RAM.
 
Old 12-21-2019, 01:48 PM   #4148
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,990
Blog Entries: 2

Rep: Reputation: 658Reputation: 658Reputation: 658Reputation: 658Reputation: 658Reputation: 658
I used to use either and can only highly recommend to have a switch handy - maybe the rc. way and a helper in the task bar?

The /tmp on ram keeps it tidy, clean, fast and saves a lot of traffic on SSD

The constrained amount of RAM makes for mysterious errors on copying huge files or doing massive package build queues.

I would so gladly taste the best of both worlds if possible...
 
Old 12-21-2019, 09:50 PM   #4149
elyk
Member
 
Registered: Jun 2004
Distribution: Slackware
Posts: 239

Rep: Reputation: 48
I was able to get a working i586 version of rust and firefox.

For rust, run `ARCH=i586 ./rust.SlackBuild` from a modern machine. I had various compile-time errors with 1.39.0, but 1.40.0 seems to work. 1.36.0 from 14.2 also seems to work. However, the binaries are still contaminated with SSE2 instructions, I suspect from clang's default behavior of generating pentium4 code that I mentioned previously, in combination with $SLKCFLAGS being ignored. So I did this, under the assumption that it'll compile using gcc and its sane defaults:

Code:
--- a/rust.SlackBuild
+++ b/rust.SlackBuild
@@ -237,17 +237,7 @@
   fi
 fi
 
-if [ "$ARCH" = "armv7hl" ] ; then
-  python x.py dist
-else
-  # README.md says gcc 4.7 / clang 3.x or later needed
-  # but building fails for me with GCC 5.3 from slackware 14.2
-  export CC=clang
-  export CXX=clang++
-  CFLAGS="$SLKCFLAGS" \
-  CXXFLAGS="$SLKCFLAGS" \
-  python x.py dist  || exit 1
-fi
+python x.py dist || exit 1
 
 DESTDIR=$PKG python x.py install || exit 1
Success! No more illegal instruction errors from rustc or cargo. On to compiling firefox. I noticed its nodejs dependency adding -msse2 to the build flags, so I removed it:

Code:
--- a/deps/v8/gypfiles/toolchain.gypi
+++ b/deps/v8/gypfiles/toolchain.gypi
@@ -1019,15 +1019,6 @@
           },
         },
       }],
-      ['(OS=="linux" or OS=="freebsd" or OS=="openbsd" or OS=="solaris" \
-         or OS=="netbsd" or OS=="mac" or OS=="android" or OS=="qnx") and \
-        v8_target_arch=="ia32"', {
-        'cflags': [
-          '-msse2',
-          '-mfpmath=sse',
-          '-mmmx',  # Allows mmintrin.h for MMX intrinsics.
-        ],
-      }],
       ['(OS=="linux" or OS=="freebsd" or OS=="openbsd" or OS=="solaris" \
          or OS=="netbsd" or OS=="mac" or OS=="android" or OS=="qnx") and \
         (v8_target_arch=="arm" or v8_target_arch=="ia32" or \
Next, firefox does some configure-time checks and gets confused that rustc can target both i586-unknown-linux-gnu and i686-unknown-linux-gnu. A couple more patches, the first to always pass --host and --target so we can run `ARCH=i586 ./mozilla-firefox.SlackBuild` without it guessing we want i686:

Code:
--- a/mozilla-firefox.SlackBuild
+++ b/mozilla-firefox.SlackBuild
@@ -77,10 +77,8 @@
 # Firefox has been requiring more and more memory, especially while linking
 # libxul. If it fails to build natively on x86 32-bit, it can be useful to
 # attempt the build using an x86_64 kernel and a 32-bit userspace. Detect this
-# situation and set the ARCH to i686. Later in the script we'll add some
-# options to the .mozconfig so that the compile will do the right thing.
+# situation and set the ARCH to i686.
 if [ "$(uname -m)" = "x86_64" -a "$(file -L /usr/bin/gcc | grep 80386 | grep 32-bit)" != "" ]; then
-  COMPILE_X86_UNDER_X86_64=true
   ARCH=i686
 fi
 
@@ -225,6 +223,8 @@
 
 # Our building options, in a configure-like display ;)
 OPTIONS="\
+  --host=$ARCH-pc-linux-gnu \
+  --target=$ARCH-pc-linux-gnu \
   --enable-official-branding \
   --prefix=/usr \
   --libdir=/usr/lib${LIBDIRSUFFIX} \
@@ -291,12 +291,6 @@
 echo "export CC=\"${CC}\"" >> .mozconfig
 echo "export CXX=\"${CXX}\"" >> .mozconfig
 
-if [ "$COMPILE_X86_UNDER_X86_64" = "true" ]; then
-  # Compile for i686 under an x86_64 kernel:
-  echo "ac_add_options --host=i686-pc-linux-gnu" >> .mozconfig
-  echo "ac_add_options --target=i686-pc-linux-gnu" >> .mozconfig
-fi
-
 # Add the $OPTIONS above to .mozconfig:
 for option in $OPTIONS; do echo "ac_add_options $option" >> .mozconfig; done
The second patch to fix the parsing of `rustc --print target-list`, where it treats both i586 and i686 as interchangeable "x86" and prefers the last one it sees, which happens to be i686 and doesn't match `rustc -Vv`'s i586 output:

Code:
--- a/build/moz.configure/rust.configure
+++ b/build/moz.configure/rust.configure
@@ -200,7 +200,7 @@
         key = (t.cpu, endianness, t.os)
         if key in per_os:
             previous = per_os[key]
-            per_raw_os[(previous.cpu, previous.endianness,
+            per_raw_os[(previous.raw_cpu, previous.endianness,
                         previous.raw_os)] = previous
             del per_os[key]
             ambiguous.add(key)
@@ -212,7 +212,7 @@
             # normalize.
             if raw_os == 'androideabi':
                 raw_os = 'linux-androideabi'
-            per_raw_os[(t.cpu, endianness, raw_os)] = t
+            per_raw_os[(t.raw_cpu, endianness, raw_os)] = t
         else:
             per_os[key] = t
     return namespace(per_os=per_os, per_raw_os=per_raw_os)
@@ -270,11 +270,10 @@
             if rustc_target:
                 break
 
+        if rustc_target is None:
             rustc_target = rust_supported_targets.per_raw_os.get(
-                (host_or_target_cpu, host_or_target.endianness,
+                (host_or_target.raw_cpu, host_or_target.endianness,
                  host_or_target_raw_os))
-            if rustc_target:
-                break
 
         if rustc_target is None:
             die("Don't know how to translate {} for rustc".format(
 
5 members found this post helpful.
Old 12-22-2019, 01:43 AM   #4150
drgibbon
Senior Member
 
Registered: Nov 2014
Distribution: Slackware64 -current
Posts: 1,112

Rep: Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817
Quote:
Originally Posted by hpfeil View Post
I noticed n/openssl10-1.0.2u-x86_64-1.txz among the current updates. Which packages still require that? Openssl.org suggests "All users of 1.0.2 are encouraged to upgrade to 1.1.1 as soon as possible." In less than a fortnight, 1.0.2 will no longer be supported. Is there a compelling reason to continue carrying v1.0.2?
Yeah, according to OpenSSL, security fixes for 1.0.2 are only available on paid contracts after Dec 31st 2019:
Quote:
Note: The latest stable version is the 1.1.1 series. This is also our Long Term Support (LTS) version, supported until 11th September 2023. Our previous LTS version (1.0.2 series) will continue to be supported until 31st December 2019 (security fixes only during the last year of support). All users of 1.0.2 are encouraged to upgrade to 1.1.1 as soon as possible. Extended support for 1.0.2 to gain access to security fixes beyond 31st December 2019 is available.
 
2 members found this post helpful.
Old 12-22-2019, 04:22 AM   #4151
NonNonBa
Member
 
Registered: Aug 2010
Distribution: Slackware
Posts: 192

Rep: Reputation: Disabled
Quote:
Originally Posted by upnort View Post
Point taken, but I mentioned nothing about being the default. The fstab suggestion is commented. By default the rc.tmpfs suggestion can be chmod -x. Both approaches could contain warnings about exceeding the capacity of actual RAM.
Do we really need a new rc.*? Personally, I've just been symlinking /dev/shm as /tmp for years. I never ran in any problem which was not chair-keyboard-interface related (WONTFIX), even with 1GB of tmpfs. YMMV, of course, according to your habits and the software you use, but in all cases Slackware will respect your symlinks.
 
1 members found this post helpful.
Old 12-22-2019, 10:37 AM   #4152
gouttegd
Member
 
Registered: Nov 2019
Location: London, UK
Distribution: Slackware
Posts: 76

Rep: Reputation: 135Reputation: 135
Incorrect CFLAGS in eigen3ís pkgconfig file

The pkgconfig file for the l/eigen3 package (in /usr/share/pkgconfig/eigen3.pc) does not contain the proper path to the headers. It says:
Code:
Cflags: -I${prefix}//usr/include/eigen3
where it should rather say:
Code:
Cflags: -I${prefix}/include/eigen3
This is due to the use of the -DEIGEN_INCLUDE_INSTALL_DIR flag in eigen3ís SlackBuild. This flag is no longer necessary since commit b836acb7. Without that flag, the headers are still installed in /usr/include/eigen3, and the generated pkgconfig file contains the correct path.
 
3 members found this post helpful.
Old 12-22-2019, 12:18 PM   #4153
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware
Posts: 1,893

Rep: Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157Reputation: 1157
Quote:
Do we really need a new rc.*? Personally, I've just been symlinking /dev/shm as /tmp for years.
As I remember, when compiled into the kernel, /dev/shm is a POSIX requirement and must always be present and assigned to tmpfs. /tmp is part of the FHS and is considered non-persistent temporary storage and can be assigned to tmpfs if desired but is not required to be. /var/tmp is part of the FHS and is considered persistent temporary storage and should never be assigned to tmpfs.

While often functional for some people, /dev/shm is not a replacement for /tmp. The idea of /dev/shm is a non-persistent shared memory location, such as IPC or read-only file systems.

By default tmpfs is half the amount of installed RAM. This is configurable. An rc.tmpfs file, along with a respective /etc/default/tmpfs file, provides a convenient way to configure tmpfs and whether /tmp should be assigned to tmpfs.

If not wanted then chmod -x rc.tmpfs leaves everything as is. A /etc/default/tmpfs file could still be used to define the size of tmpfs with rc.S sourcing that file if the file exists. Whether /tmp should be assigned to tmpfs could be relegated to /etc/default/tmpfs, which could eliminate the need for rc.tmpfs.

Systems with low RAM probably should not be assigning /tmp to tmpfs, but /dev/shm must still exist for shared memory processes.

With respect to compiling software and the possibility of running out of space because /tmp is assigned to tmpfs, I have seen this happen but is the exception and far from the norm. Experienced people who compile software will understand the problem and can adjust.

With respect to people who want to retain their build environments, perhaps /tmp is not a good location and build scripts should be modified to use /var/tmp instead.

All of this would be configurable by the user. There are different ways in which all of this is handled in other distros. All I am proposing is a convenient one-stop location for the configuration in Slackware because currently non exist.
 
Old 12-22-2019, 06:05 PM   #4154
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,990
Blog Entries: 2

Rep: Reputation: 658Reputation: 658Reputation: 658Reputation: 658Reputation: 658Reputation: 658
Quote:
Originally Posted by upnort View Post
As I remember, when compiled into the kernel, /dev/shm is a POSIX requirement and must always be present and assigned to tmpfs. /tmp is part of the FHS and is considered non-persistent temporary storage and can be assigned to tmpfs if desired but is not required to be. /var/tmp is part of the FHS and is considered persistent temporary storage and should never be assigned to tmpfs.

While often functional for some people, /dev/shm is not a replacement for /tmp. The idea of /dev/shm is a non-persistent shared memory location, such as IPC or read-only file systems.

By default tmpfs is half the amount of installed RAM. This is configurable. An rc.tmpfs file, along with a respective /etc/default/tmpfs file, provides a convenient way to configure tmpfs and whether /tmp should be assigned to tmpfs.

If not wanted then chmod -x rc.tmpfs leaves everything as is. A /etc/default/tmpfs file could still be used to define the size of tmpfs with rc.S sourcing that file if the file exists. Whether /tmp should be assigned to tmpfs could be relegated to /etc/default/tmpfs, which could eliminate the need for rc.tmpfs.

Systems with low RAM probably should not be assigning /tmp to tmpfs, but /dev/shm must still exist for shared memory processes.

With respect to compiling software and the possibility of running out of space because /tmp is assigned to tmpfs, I have seen this happen but is the exception and far from the norm. Experienced people who compile software will understand the problem and can adjust.

With respect to people who want to retain their build environments, perhaps /tmp is not a good location and build scripts should be modified to use /var/tmp instead.

All of this would be configurable by the user. There are different ways in which all of this is handled in other distros. All I am proposing is a convenient one-stop location for the configuration in Slackware because currently non exist.
This is actually quite reasonable IMHO
 
Old 12-22-2019, 09:47 PM   #4155
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,558

Original Poster
Rep: Reputation: 1312Reputation: 1312Reputation: 1312Reputation: 1312Reputation: 1312Reputation: 1312Reputation: 1312Reputation: 1312Reputation: 1312Reputation: 1312
Here's what I do locally on my systems:
Code:
# diff -u /etc/rc.d/rc.S.new /etc/rc.d/rc.S
--- /etc/rc.d/rc.S.old	2019-01-21 19:27:02.000000000 -0600
+++ /etc/rc.d/rc.S	2019-05-18 00:13:38.700863732 -0500

@@ -367,6 +369,9 @@
   /sbin/mount -a -v -t nonfs,nosmbfs,nocifs,noproc,nosysfs | grep successfully | cut -f 1 -d : | tr -d ' ' | while read dev ; do mount | grep " ${dev} " ; done
 fi
 
+# Create a bind mount from /run to /var/run
+mount --bind /run /var/run
+
 # Enable swapping again.  This is needed in case a swapfile is used,
 # as it can't be enabled until the filesystem it resides on has been
 # mounted read-write.
@@ -384,10 +389,8 @@
 fi
 
 # Clean up some temporary files:
-rm -f /var/run/* /var/run/*/* /var/run/*/*/* /etc/nologin \
-  /etc/dhcpc/*.pid /etc/forcefsck /etc/fastboot \
-  /var/state/saslauthd/saslauthd.pid \
-  /tmp/.Xauth* 1> /dev/null 2> /dev/null
+rm -f /etc/nologin /etc/dhcpc/*.pid /etc/forcefsck /etc/fastboot \
+  /var/state/saslauthd/saslauthd.pid /tmp/.Xauth* 1> /dev/null 2> /dev/null
 if [ -d /var/lib/pkgtools/setup/tmp ]; then
   ( cd /var/lib/pkgtools/setup/tmp && rm -rf * )
 elif [ -d /var/log/setup/tmp ]; then
You'll want to clean out the on-disk /var/run *before* you do this, and I find that the easiest way is to do this:
Code:
# mv /var/run/* /run/
# mount --bind /run /var/run
I need to stress that the changes in rc.S to the "clean up temporary files" stuff is absolutely necessary, or else you'll remove at least one thing that's needed for a fully working system (the udev socket), so be sure you include that - i.e. it's not as simple as just bind mounting /var/run to /run at boot.

I also have this on all of the systems I admin:

Code:
# grep tmpfs /etc/fstab
tmpfs                  /tmp                   tmpfs   mode=1777,size=1G,nosuid,nodev,noexec        0 0
tmpfs                  /var/tmp               tmpfs   mode=1777,size=256M,nosuid,nodev,noexec      0 0
tmpfs                  /var/cache             tmpfs   mode=0755,size=256M,nosuid,nodev,noexec      0 0
tmpfs                  /var/lock              tmpfs   mode=1777,size=32M,nosuid,nodev,noexec       0 0
tmpfs                  /dev/shm               tmpfs   defaults,size=4G,nosuid,nodev,noexec         0 0
tmpfs                  /root/tmp              tmpfs   mode=0700,size=6G                            0 0
The size of /dev/shm can vary, of course, depending on the system's specs and intended usage and such.
The /root/tmp directory addresses the issue raised above about compiling - I used /root/tmp as TMP and TMPDIR for everything root does (including compiling, and that's declared in root's $HOME/.bashrc, which is sourced from $HOME/.profile here). I could of course leave /root/tmp on disk, or it could be anywhere else if desired.
Also, yes, I know that /var/tmp is intended to be persistent. That's nice. I don't care. :-)
 
4 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Requests for -current (20151216) rworkman Slackware 3441 12-28-2017 03:50 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 01:06 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration