Slackware 14.1 Release Candidate 2

Darth Vader · 10-22-2013, 10:01 AM

While not a bug, it would be great if XZ and LIBARCHIVE while be recompiled with --enable-static switch activated.

This rebuild has no side effects on distribution, only add two little .a archives to system, but it would simplify my life (and of my colleagues too), where I work, because we use several (in-house) applications that are linked statically with these libraries.

Every time them are updated, we must remember to do to these two packages a rebuild, for enabling the static archives.

PS. Too much to ask, also, for a GDBM update, now? It is now (from loooong time) at 1.10 version. Also, it is practically unused by another Slackware packages, but we use it, too...

mancha · 10-22-2013, 10:28 AM

Quote:

Originally Posted by a4z

any special reasons for this permissions?

How about this change to the SlackBuild:

Code:

--- xfig.SlackBuild.orig        2013-09-18
+++ xfig.SlackBuild             2013-10-22
@@ -58,6 +58,8 @@
   \( -perm 2775 -o -perm 777 -o -perm 775 -o -perm 711 -o -perm 555 -o -perm 511 \) \
   -exec chmod 755 {} \; -o \
   \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \
+  -exec chmod 644 {} \; -o \
+  \( -perm 700 -type f \) \
   -exec chmod 644 {} \;
 
 #zcat $CWD/xfig-3.2.4-mkstemp.diff.gz | patch -E -p1 --verbose || exit 1

--mancha

AlleyTrotter · 10-22-2013, 11:26 AM

Quote:

Originally Posted by Didier Spaier

Installing Slackware64 14.1 rc2 in an EFI enabled VM through vmplayer, even choosing the no KMS menu entry of grub (aka nomodeset), handover occurs and output of "cat /proc/fb" is:
0 svgadrmfb
Is it a limitation of vmplayer or does someone observe the same behavior on a real machine or with another virtualization tool?

Here with a real EFI machine using current dated Tue Oct 22 03:06:58 UTC 2013

Option 1 Without KMS console -> '0 EFI VGA'
Option 2 With KMS Console -> '0 inteldrmfb'

After install and reboot I get -> '0 inteldrmfb'

Hope this answers your question
John

Didier Spaier · 10-22-2013, 11:38 AM

Quote:

Originally Posted by AlleyTrotter

Here with a real EFI machine using current dated Tue Oct 22 03:06:58 UTC 2013

Option 1 Without KMS console -> '0 EFI VGA'
Option 2 With KMS Console -> '0 inteldrmfb'

After install and reboot I get -> '0 inteldrmfb'

Hope this answers your question
John

Yes, thanks John. So, that's most probably due to vmplayer (maybe some setting can change that behavior, but I won't investigate further :-)

hpfeil · 10-22-2013, 01:10 PM

[The new kernel packages don't appear to change anything in /boot except the timestamp of the links.] <<-- Old habit of using `installpkg` on kernel, modules and src. Vestial custom kernel behavior so it is easy to revert to previous working version if the new compile doesn't boot. Using `upgradepkg` does indeed upgrade versions.

The source tree for xfce does not contain executable xfce*.SlackBuilds. It's easy to fix, just add 'sh ' to the SlackBuild invocation in xfce-build-all.sh.

Code:

--- xfce-build-all.sh	2013-10-22 11:07:30.730000000 -0700
+++ xfce-build-all.sh.fix	2013-10-22 11:07:14.162000000 -0700
@@ -58,7 +58,7 @@
   xfce4-weather-plugin \
   ; do
   cd $package || exit 1
-  ./${package}.SlackBuild || ( touch /tmp/${package}.failed ; exit 1 ) || exit 1
+  sh ./${package}.SlackBuild || ( touch /tmp/${package}.failed ; exit 1 ) || exit 1
   if [ "$INST" = "1" ]; then
     PACKAGE="$(ls -t $TMP/$(ls ${package}*.xz | rev | cut -f2- -d - | rev)-*txz | head -n 1)"
     if [ -f $PACKAGE ]; then

Alien Bob · 10-22-2013, 02:14 PM

Quote:

Originally Posted by hpfeil

[The new kernel packages don't appear to change anything in /boot except the timestamp of the links.]

Oh but there are real changes!

Code:

-rw-r--r--  1 root root  3455792 Oct 20 23:13 vmlinuz-generic-3.10.17
-rw-r--r--  1 root root   137802 Oct 20 23:13 config-generic-3.10.17
-rw-r--r--  1 root root  2213519 Oct 20 23:13 System.map-generic-3.10.17
lrwxrwxrwx  1 root root       23 Oct 21 20:56 vmlinuz -> vmlinuz-generic-3.10.17
lrwxrwxrwx  1 root root       22 Oct 21 20:56 config -> config-generic-3.10.17
lrwxrwxrwx  1 root root       26 Oct 21 20:56 System.map -> System.map-generic-3.10.17
d

Quote:

The source tree for xfce does not contain executable xfce*.SlackBuilds. It's easy to fix, just add 'sh ' to the SlackBuild invocation in xfce-build-all.sh.

Code:

--- xfce-build-all.sh	2013-10-22 11:07:30.730000000 -0700
+++ xfce-build-all.sh.fix	2013-10-22 11:07:14.162000000 -0700
@@ -58,7 +58,7 @@
   xfce4-weather-plugin \
   ; do
   cd $package || exit 1
-  ./${package}.SlackBuild || ( touch /tmp/${package}.failed ; exit 1 ) || exit 1
+  sh ./${package}.SlackBuild || ( touch /tmp/${package}.failed ; exit 1 ) || exit 1
   if [ "$INST" = "1" ]; then
     PACKAGE="$(ls -t $TMP/$(ls ${package}*.xz | rev | cut -f2- -d - | rev)-*txz | head -n 1)"
     if [ -f $PACKAGE ]; then

That will be a problem on your local end. I checked a couple of mirrors (the ones I have local access to) as well as the original file tree, and all SlackBuild scripts inside the source/xfce tree are executable.

Perhaps you downloaded to a filesystem that has the noexec bit set?

Eric

afreitascs · 10-22-2013, 02:36 PM

Quote:

Originally Posted by LukenShiro

I've noticed a tiny problem: slackpkg package's version and shell script's version are not aligned:

/var/log/packages/:
slackpkg-2.82.0-noarch-12

but:

# slackpkg
slackpkg - version 2.81.1
[..]

even here ...

Didier Spaier · 10-22-2013, 04:38 PM

man-pages.SlackBuild replaces man pages pthread_* maintained by Michael Kerrisk by those coming from posix-2003, that are older and probably (at least some) not up to date, so I suggest to remove the latter from the package. Anyhow, current version of these is accessible on line.

But I would like that French man pages be added

Denis Barbier told me that they are available there.

I modified the slackbuild to add them and remove the old posix ones, patch is attached.

FWIW

jtsn · 10-23-2013, 09:48 AM

Quote:

Originally Posted by Didier Spaier

man-pages.SlackBuild replaces man pages pthread_* maintained by Michael Kerrisk by those coming from posix-2003, that are older and probably (at least some) not up to date, so I suggest to remove the latter from the package. Anyhow, current version of these is accessible on line.

Actually, the POSIX standard is more recent. The Linux implementation is conformant to POSIX-1.2001.

Quote:

But I would like that French man pages be added

Denis Barbier told me that they are available there.

I modified the slackbuild to add them and remove the old posix ones, patch is attached.

These localized manpages should be added as a separate package with a correct version number.

And I like my POSIX man pages, all of them, not only the pthread ones. It's nice to have them for reference. Of course, they should go into the correct (separate) directory.

GazL · 10-23-2013, 10:58 AM

I think this is another little issue we've had for a release or two now:

xconsole reads /dev/xconsole by default, but there's no such device file. I did a
"ln -sf console /lib/udev/devices/xconsole" so that udev creates it.

Not sure if this is the correct approach or not but that seems to have sorted it out. *

xterm -C still gives "xterm: cannot open console: Operation not permitted" though, so I'm not sure what's going on there.

update: Scatch that, while it allows xconsole to open, as soon as you enable writing to /dev/console in syslog.conf it goes wappy, so that's not the correct fix!

Update 2: sussed it.
It looks like it should be a named pipe: mknod -m 640 /dev/xconsole p which syslog.conf can then be configured to write to. Now what I'm not sure about is whether rc.syslog or udev should be creating this thing. I'm tempted to give it root:users permissions so that any user can use it, but common practice seems to be root:adm. 'xterm -C' still doesn't work though.

Didier Spaier · 10-23-2013, 03:46 PM

Quote:

Originally Posted by jtsn

These localized manpages should be added as a separate package with a correct version number.

You're right. So my request becomes "Please include man-page-fr (source material attached, but the source tarball https://alioth.debian.org/frs/downlo...-3.53-1.tar.xz) to Slackware-14.1 if still possible".

Quote:

Originally Posted by jtsn

And I like my POSIX man pages, all of them, not only the pthread ones. It's nice to have them for reference. Of course, they should go into the correct (separate) directory.

Agreed. That way both versions will be available.

Drakeo · 10-23-2013, 04:27 PM

looking at the x86 config-huge-3.10.17 see that it is only set to 4 gigs of ram. there is so many supported programs in 32 bit and still huge amount of development in the 32 bit software. But today's machines 4 gigs is becoming a small amount.
Not a big deal to me I just recompile the kernel and enable it. Wonder if you might think in the future on having huge PAE.

What I do see is very nice is the config-generic-smp-3.10.17-smp it is enabled 64M.
and as people should learn and do is create that intrid.img for the generic.
any plans on a Large sized pre-built generic initrd.img in the future

I been using Alien Bobs script for a long time.the now used (mkinitrd_command_generator.sh) To help create the initrd.img. Slackware beginners guide
as a person that has to Admin many linux boxes I am glad you find a kernel and stay with it for a while.
slackware14.1 rc2 nice job all my multimedia stuff doing great. Not going to go there on Multilib stuff yet.
that's down the road.

volkerdi · 10-23-2013, 04:31 PM

Quote:

Originally Posted by Drakeo

looking at the x86 config-huge-3.10.17 see that it is only set to 4 gigs of ram. there is so many supported programs in 32 bit and still huge amount of development in the 32 bit software. But today's machines 4 gigs is becoming a small amount.
Not a big deal to me I just recompile the kernel and enable it. Wonder if you might think in the future on having huge PAE.

As the documentation notes, if your machine can run the SMP kernel, it is recommended to use that. It has PAE support (and other optimizations).

The non-SMP kernel has no PAE support because there are many machines still in use that have no PAE support (Pentium M, for example). So we will not be enabling PAE in the non-SMP kernel.

hitest · 10-23-2013, 07:55 PM

I am really looking forward to 14.1. I have four Slackware boxen that will be upgraded.

P.S. Now is a great time to consider buying a Slackware subscription. I have one. I am looking forward to the arrival of my 14.1 DVD.

1337_powerslacker · 10-23-2013, 09:25 PM

Quote:

Originally Posted by hitest

I am really looking forward to 14.1. I have four Slackware boxen that will be upgraded.

P.S. Now is a great time to consider buying a Slackware subscription. I have one. I am looking forward to the arrival of my 14.1 DVD.

I have taken the liberty of downloading Slackware64 14.1 RC2 as of today (10/23/13), and installed it. I am happy to say that it is looking beautiful, running fast, and stable as a rock; but then, I have come to expect that out of Slackware.

I have also pre-ordered the Slackware release. I cannot think of money that is better spent (and certainly not on a company based in Washington state).

Regards,

Matt