[SOLVED] Requests for -current (20151216)

elcore · 01-10-2016, 02:53 PM

If --disable-dbus is used you must use --disable-necko-wifi flag too, it depends on dbus, though I admit I have no idea what it's supposed to do.
Probably useless on a wired desktop, so I disabled that, and quite a lot of other features, like --disable-webrtc --disable-bundled-fonts and --disable-webapp-runtime
Sometimes firefox is very sketchy about the flags, some of them build, some don't, for example --disable-eme doesn't seem to do anything at all, it still loads extensions if that flag is used.
EME and Pocket seem absent from GNU IceCat, and this is one of the main reasons why I switched. It also builds fine with some flags where firefox just throws error (2) for no apparent reason.

cwizardone · 01-10-2016, 05:36 PM

The 4.4 Kernel has been released.

AlleyTrotter · 01-10-2016, 06:34 PM

Quote:

Originally Posted by cwizardone

The 4.4 Kernel has been released.

Using 4.4.0 now just built using make oldconfig and accepting all new defaults.
So far so good
john

elcore · 01-11-2016, 12:01 AM

Quote:

Originally Posted by cwizardone

The 4.4 Kernel has been released.

Builds fine, just made one 4.4-smp for 14.1 with localmodconfig and then tainted it with nvidia binary.

aaazen · 01-11-2016, 12:27 AM

Quote:

Originally Posted by Wiser Slacker

Hi -
have tested -current on old Laptop (32 bit) and found "xapm" is buggy. It seemed it had not been compiled in the right way. If it was started - it tells something like " ... try to compile ... this should never happen."
It is no binary - it is a shell script.
If i should test something - please tell me.
...
Slacker

This is a great question as it brings a chance to clean up some old code.

First of all, there appears to be a bug in the apmd.SlackBuild script for installing xapm.

The script installs an xapm shell script which clearly states in the comments at the top:

Quote:

# This wrapper script should never be moved out of the build directory.
# If it is, it will not operate correctly.

Instead the apmd.SlackBuild script should probably install the xapm binary which is in the .libs subdirectory.

Here is a patch to the build script:

Code:

--- apmd.SlackBuild.orig	2011-04-10 23:19:53.000000000 -0700
+++ apmd.SlackBuild	2016-01-10 18:31:59.202738416 -0800
@@ -21,7 +21,7 @@
 #  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 VERSION=${VERSION:-3.2.2}
-BUILD=${BUILD:-3}
+BUILD=${BUILD:-4}
 
 # Automatically determine the architecture we're building on:
 if [ -z "$ARCH" ]; then
@@ -76,7 +76,7 @@
 )
 
 mkdir -p $PKG/usr/bin
-cat xapm > $PKG/usr/bin/xapm
+cat .libs/xapm > $PKG/usr/bin/xapm
 cat xbattery/xbattery > $PKG/usr/bin/xbattery
 chmod 755 $PKG/usr/bin/{xapm,xbattery}

Second, the Slackware kernels starting with 14.0 including 14.1 and current do not configure APM by default. They have ACPI on but not APM.

To actually use APM instead of ACPI one needs to rebuild the kernel with CONFIG_APM=m

It appears that it is still okay to configure a kernel with both APM and ACPI:

https://www.kernel.org/doc/Documenta...r/apm-acpi.txt

And after rebuilding the kernel with APM support, then to make sure that APM is used and not APCI, then
add this to the kernel parameters at boot time: "acpi=off apm=on"

And after booting load the apm module: #loadmod apm

-------------------------------------------------------------------

Or just forget about APM and try to use ACPI to begin with?

ACPI seems to be the new standard...

And this brings up another question. If Slackware no longer configures APM in the kernel should the apmd package be moved to "pasture"?

elyk · 01-11-2016, 12:28 AM

The default $MANPATH is /usr/local/man:/usr/man. Just about every build from source puts man pages in ${prefix}/share/man, and we have to adjust --mandir (also --infodir and --docdir) to put them in Slackware's preferred spot.

aaa_base creates symlinks from /usr/share/{man,info,doc} to /usr/{man,info,doc}, but it doesn't create them for /usr/local. If you do a quick `./configure && make && make install`, the man pages usually get installed to /usr/local/share/man (not in $MANPATH) and aren't found.

I've noticed this with man pages. Not sure if there's anything equivalent for info pages. On my machine I've changed $MANPATH to /usr/local/share/man:/usr/share/man to deal with it.

elyk · 01-11-2016, 12:33 AM

I'd like to see a default .bash_profile script in /etc/skel, something like this:

Code:

case $- in
	*i*)  # Interactive shell
		[ -f ~/.bashrc ] && . ~/.bashrc
		;;
esac

ReaperX7 · 01-11-2016, 02:24 AM

Quote:

Originally Posted by cwizardone

The 4.4 Kernel has been released.

Testing 4.4 also. Checked all the new stuff before just accepting the defaults.

allend · 01-11-2016, 07:24 AM

Quote:

Originally Posted by elyk

The default $MANPATH is /usr/local/man:/usr/man. Just about every build from source puts man pages in ${prefix}/share/man, and we have to adjust --mandir (also --infodir and --docdir) to put them in Slackware's preferred spot.

aaa_base creates symlinks from /usr/share/{man,info,doc} to /usr/{man,info,doc}, but it doesn't create them for /usr/local. If you do a quick `./configure && make && make install`, the man pages usually get installed to /usr/local/share/man (not in $MANPATH) and aren't found.

I've noticed this with man pages. Not sure if there's anything equivalent for info pages. On my machine I've changed $MANPATH to /usr/local/share/man:/usr/share/man to deal with it.

This is an interesting point.
On my setup, currently /usr/local/man has the subdirectories created by aaa-base but is not populated. However /usr/local/share/man is populated with files from third party software.
According to the FHS, these directories should be synonymous.
I also note this comment from the FHS

Quote:

/usr/local/man may be deprecated in future FHS releases, so if all else is equal, making that one a symlink seems sensible.

This would suggest that altering aaa-base to create subdirectories in /usr/local/share/man and also making /usr/local/man a symlink to /usr/local/share/man is worth consideration.

55020 · 01-11-2016, 07:53 AM

Well...

First, that's an obsolete version of the FHS, and FHS 3.0 does not say anything about such a symlink. Instead, it says this:

Quote:

Manual pages for commands and data under /usr/local are stored in /usr/local/man or /usr/local/share/man. All manual page hierarchies in the system must have the same structure as /usr/share/man, as this structure is expected by commands which consume manual page content. [34]
[...]
[34] /usr/local/man is deprecated and may be dropped in a future version of this specification.

Secondly, from observation Slackware hasn't always followed the FHS and LSB (in particular w.r.t. /usr/man and /usr/share/man)

Thirdly, having read some of the FHS revision discussions, one might think that the barbarians are through the gate now and heading for the keep

And fourthly, since the FHS is part of the LSB, and the LSB is dying or even dead now, the barbarians are welcome to it

bassmadrigal · 01-11-2016, 09:15 AM

Quote:

Originally Posted by 55020

First, that's an obsolete version of the FHS, and FHS 3.0...

I didn't know they finalized the release of 3.0 (back in June of 2015, so I am a bit slow). Thanks for the heads up!

michelino · 01-11-2016, 10:31 AM

+1 for kernel 4.4, for skylake kernel support

It's also a LTS ending in Feb 2018...exactly in time for the Slackware-15.0 release!
:-)))

GazL · 01-11-2016, 11:07 AM

Built and installed 4.4.0 here this afternoon: seems ok so far, but it's going to be a few days before any issues start to show up. If 4.4.y proves itself reliable then I expect Pat will take advantage of it without need of any prompting.

USUARIONUEVO · 01-11-2016, 01:41 PM

4.4.0 kernel , no workin well here.

In a machine with mechanic hdd all plays well.

In a machine with SSD HARD DISK , write/read slowest ever.

xflow7 · 01-11-2016, 03:07 PM

Quote:

Originally Posted by elyk

I'd like to see a default .bash_profile script in /etc/skel, something like this:

Code:

case $- in
	*i*)  # Interactive shell
		[ -f ~/.bashrc ] && . ~/.bashrc
		;;
esac

Is this necessary? Doesn't bash run .bashrc for interactive shells anyway?

Dave