LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Slackware 14.1 Release Candidate 2 (https://www.linuxquestions.org/questions/slackware-14/slackware-14-1-release-candidate-2-a-4175481594/)

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 (Post 5050353)
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 (Post 5050277)
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 (Post 5050418)
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 (Post 5050466)
[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 (Post 5050273)
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 ... :confused:

Didier Spaier 10-22-2013 04:38 PM

request: remove man-page-posix, add man-pages-fr
 
1 Attachment(s)
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 (Post 5050562)
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

Request: please add man-pages-fr to Slackware 14.1
 
2 Attachment(s)
Quote:

Originally Posted by jtsn (Post 5050944)
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 (Post 5050944)
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 (Post 5051141)
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 (Post 5051217)
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


All times are GMT -5. The time now is 09:38 AM.