[SOLVED] Requests for -current (20151216)

gmgf · 07-13-2017, 01:53 AM

Sysstat 11.4.5 released (stable version)

http://sebastien.godard.pagesperso-orange.fr/
http://perso.orange.fr/sebastien.god...-11.4.5.tar.xz

samba-4.6.6:

https://www.samba.org/
(These are security releases in order to address CVE-2017-11103 (Orpheus' Lyre mutual authentication validation bypass)
https://download.samba.org/pub/samba...a-4.6.6.tar.gz

Didier Spaier · 07-13-2017, 03:32 AM

Well, as far as I know elvis still does not have UTF-8 support even in the (unofficial?) git repo and if I can trust what I read there are not much features available in elvis but not in vim.

I realize that elvis is smaller. Maybe move it to /pasture or /extra?

I guess that our BDFL will not welcome this suggestion (but didn't he migrate to vim himself?). Waiting for the flame war to begin

PS This is my post #7500 @ LQ. Maybe I should have waited to reach #10000...

GazL · 07-13-2017, 05:40 AM

I've always preferred elvis over vim, but lack of mbcs support is a severe impediment to its usefulness and given the move to default utf8 in the next release now is probably the time to address this. Anyone still running sbcs will likely still find it useful, so /pasture seems like a good option.

ponce · 07-13-2017, 06:22 AM

I personally switch to vim as one of the first post-install operations but I just change the /usr/bin/vi symlink to point to /usr/bin/vim.

elvis is pretty useful to have installed and I bet would be still used by a lot of people also if Slackware will move to using vim by default (there's also who is using the real ex out there, not the symlink to vim) so, IMHO, I would opt to just changing the symlink and not moving it away from the default install...

allend · 07-13-2017, 07:19 AM

Quote:

who push this bullshit to our beloved Slackware?

My best guess is piterpunk, who gave us the slackpkg tool. The first time I ever upgraded my Slackware install, I conducted everything manually, as there was no other option. When slackpkg came along, I was amazed at how it handled everything so easily and cleanly. As for pushing, slackpkg resided in /extra through a number of releases before becoming part of official Slackware. The long gestation allowed for thorough examination of the then new tool.

If the lilo prompt now appears dated with the appearance of (and requirement for) newer boot loaders, it simply reflects the longstanding tradition of lilo being the official Slackware boot loader. If the prompt now peeves you, why not use the clever functionality that is provided within slackpkg? Simply copy /usr/libexec/slackpkg/functions.d/post-functions.sh to a new file that lexicographically sorts after the original, amend the lookkernel() function to suit your needs along the lines suggested by Loomx, then enjoy your local customisation. I have being doing this for years, so that I am automatically prompted to build a new initrd when required.

As a continuing user of lilo, I want the existing functionality retained.

I also appreciate that Slackware still gives a nod to past contributors to the open source community by retention of software that seems quaint and quirky to those without the history.

Perhaps this brief history might tone down some of the denigration from the nitpickers who have not given to Slackware what others have done in the past.

burdi01 · 07-13-2017, 11:53 AM

Running the 4.12.0 kernel I just built the 4.12.1 one:

Code:

root@riposo:/boot# uname -a
Linux riposo 4.12.0-burdi64 #1 SMP PREEMPT Mon Jul 3 11:28:06 CEST 2017 x86_64 Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz GenuineIntel GNU/Linux
root@riposo:/boot# mkinitrd -c -m sd_mod:ahci:ext4 -o /boot/initrd.gz-%KVER% -k 4.12.1-burdi64
OK: /lib/modules/4.12.1-burdi64/kernel/drivers/scsi/sd_mod.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/drivers/ata/libata.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/drivers/ata/libahci.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/drivers/ata/ahci.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/fs/mbcache.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/fs/crypto/fscrypto.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/fs/jbd2/jbd2.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/lib/crc16.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/fs/ext4/ext4.ko added.
43940 blocks
/boot/initrd.gz-4.12.0-burdi64 created.
Be sure to run lilo again if you use it.
root@riposo:/boot#

which overwrote my current initrd instead of creating the new 4.12.1 one.

And now with kernel 4.12.0 as well as 4.12.1 I have a hang / timeout at glib-compile-schemas. I am not sure how this relates to the above symptoms though ...

phenixia2003 · 07-13-2017, 01:21 PM

Hello,

Quote:

Originally Posted by burdi01

Running the 4.12.0 kernel I just built the 4.12.1 one:

Code:

root@riposo:/boot# uname -a
Linux riposo 4.12.0-burdi64 #1 SMP PREEMPT Mon Jul 3 11:28:06 CEST 2017 x86_64 Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz GenuineIntel GNU/Linux
root@riposo:/boot# mkinitrd -c -m sd_mod:ahci:ext4 -o /boot/initrd.gz-%KVER% -k 4.12.1-burdi64
OK: /lib/modules/4.12.1-burdi64/kernel/drivers/scsi/sd_mod.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/drivers/ata/libata.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/drivers/ata/libahci.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/drivers/ata/ahci.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/fs/mbcache.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/fs/crypto/fscrypto.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/fs/jbd2/jbd2.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/lib/crc16.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/fs/ext4/ext4.ko added.
43940 blocks
/boot/initrd.gz-4.12.0-burdi64 created.
Be sure to run lilo again if you use it.
root@riposo:/boot#

which overwrote my current initrd instead of creating the new 4.12.1 one.

And now with kernel 4.12.0 as well as 4.12.1 I have a hang / timeout at glib-compile-schemas. I am not sure how this relates to the above symptoms though ...

You found a bug in the patch I sent for mkinitrd. Sorry. In fact that's because -k is passed after -o, therefore, %KVER% is replaced by the current kernel version.

Here is a patch to fix that :

Code:

--- mkinitrd.orig	2017-07-13 19:56:42.168034365 +0200
+++ mkinitrd	2017-07-13 20:18:48.412093542 +0200
@@ -364,7 +364,7 @@
       ;;
     -o)
       # canonicalize filename:
-      OUTPUT_IMAGE="$(readlink -m $(normalize_string $2))"
+      OUTPUT_IMAGE="$(readlink -m $2)"
       shift 2
       ;;
     -r)
@@ -429,6 +429,19 @@
   esac
 done
 
+# Resolve TAGS (i.e %KVER%, %SLACKVER%) found in OUTPUT_IMAGE.
+#
+# Note:
+# ----
+# This must be done after all options have been handled and
+# not when handling case '-o' because -k can be passed after
+# -o in which case, the tag %KVER% would be replaced with the 
+# current kernel version instead of version passed with -k.
+#
+if echo "$OUTPUT_IMAGE" | grep -qE "%KVER%|%SLACKVER%" ; then
+  OUTPUT_IMAGE="$(normalize_string $OUTPUT_IMAGE)"
+fi
+
 # If kernel modules are needed but the kernel version is absent, exit now:
 if [ ! -d /lib/modules/$KERNEL_VERSION ]; then
   echo "ERROR: No /lib/modules/$KERNEL_VERSION kernel modules tree found for kernel \"$KERNEL_VERSION\""

Example :

Code:

$ mkinitrd -c -m sd_mod:ahci:ext4 -o ./initrd-%KVER%.gz -k 4.12.1-burdi64
OK: /lib/modules/4.12.1-burdi64/kernel/fs/jbd2/jbd2.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/fs/mbcache.ko added.
OK: /lib/modules/4.12.1-burdi64/kernel/fs/ext4/ext4.ko added.
35967 blocks
/tmp/mkinitrd/initrd-4.12.1-burdi64.gz created.
Be sure to run lilo again if you use it.

--
SeB

rworkman · 07-13-2017, 02:11 PM

I always pass the options in a different order, hence I didn't catch that :/
As an aside, you need this, burdi01:

Code:

CLEAR_TREE="1"
KEYMAP="us"
MODULE_LIST="sd_mod:ahci:ext4"
ROOTDEV="YOUR_ROOT_DEV"
ROOTFS="ext4"
OUTPUT_IMAGE="/boot/initrd.gz-%KVER%"

Then you can just do this:

Code:

mkinitrd -F -k 4.12.1-burdi64

gmgf · 07-14-2017, 06:47 AM

mariadb-10.0.31:

many CVE fix and also gcc7 fix

https://mariadb.com/kb/en/mariadb/ma...release-notes/
https://downloads.mariadb.org/inters...10.0.31.tar.gz

burdi01 · 07-14-2017, 09:32 AM

I can confirm the Thu Jul 13 19:24:36 UTC 2017 a/mkinitrd-1.4.11-x86_64-2.txz version to resolve my problem.

@rworkman:

Quote:

As an aside, you need this [/etc/mkinitrd.conf], burdi01:

My command is a one-line text file in my /boot directory that I update and "sh" every time for a new kernel.

USUARIONUEVO · 07-14-2017, 03:16 PM

mesa-17.1.5
ftp://ftp.freedesktop.org/pub/mesa/mesa-17.1.5.tar.xz

Quote:

New features

None

Bug fixes

Bug 100242 - radeon buffer allocation failure during startup of Factorio
Bug 101657 - strtod.c:32:10: fatal error: xlocale.h: No such file or directory
Bug 101666 - bitfieldExtract is marked as a built-in function on OpenGL ES 3.0, but was added in OpenGL ES 3.1
Bug 101703 - No stencil buffer allocated when requested by GLUT

USUARIONUEVO · 07-14-2017, 03:21 PM

gstreamer-1.12.2
https://gstreamer.freedesktop.org/sr...-1.12.2.tar.xz

and plugins
plugins-base --> https://gstreamer.freedesktop.org/sr...-1.12.2.tar.xz
plugins-good --> https://gstreamer.freedesktop.org/sr...-1.12.2.tar.xz
libav --> https://gstreamer.freedesktop.org/sr...-1.12.2.tar.xz

rworkman · 07-14-2017, 03:24 PM

Quote:

Originally Posted by phenixia2003

You found a bug in the patch I sent for mkinitrd. Sorry. In fact that's because -k is passed after -o, therefore, %KVER% is replaced by the current kernel version. Here is a patch to fix that...

Code:

... patch ...

Thanks for your work on this - it's much appreciated here!

USUARIONUEVO · 07-14-2017, 03:44 PM

icu4c-59.1
http://download.icu-project.org/file...c-59_1-src.tgz

vte-0.48.3
https://git.gnome.org/browse/vte/sna...-0.48.3.tar.xz

opencl-headers-2.2
https://github.com/KhronosGroup/Open...er/opencl22/CL

USUARIONUEVO · 07-14-2017, 04:10 PM

libjpeg-turbo-1.5.2
https://github.com/libjpeg-turbo/lib...e/1.5.2.tar.gz

very big list of fixes
https://github.com/libjpeg-turbo/libjpeg-turbo/releases