Slackware 14.1 Release Candidate 2
 

Getting much closer. :)

http://slackware.osuosl.org/slackwar.../ChangeLog.txt

Freshly rebuilt images available, use the link in my signature.

I don't know if that's the same ones as AlienBob linked to for RC1, but I noticed on those that CHECKSUMS.md5 in the root directory threw a bunch of errors because it included the source/ directory (which I understood) and some in extra/ (which surprised me). I assume this will be cleared up when the official DVDs are released. I usually check those MD5s just to make sure everything burned right.

Thanks TobiSGD,

I happily use Alien Bob's mirror-slackware-current.sh build script at his site. Eric's script builds CDs or a DVD of slackware-current.

http://slackware.com/~alien/

I use AlienBob's script to generate those images, so I would be surprised if they aren't the same as the ones he offers. Funnily, I can't find where to get AlienBob's ISOs, so that I can compare the MD5s.

http://taper.alienbase.nl/mirrors/sl...4-current-iso/ and http://taper.alienbase.nl/mirrors/sl...e-current-iso/

Eric

@TobiSGD,
This is the link I use: http://taper.alienbase.nl/mirrors/slackware/

Edit: I'm too slow.

Thanks. I got different MD5s as before when recreating the images (and they now stay consistent, so it seems there was a problem on my side), but they still do not match yours. May it be possible that your images don't have the RC2 changes already integrated?

And who says that you and I are using the same options to the script...?

Eric

I get a new checksum every time the ISO is rebuilt.

Am I to presume,then, that the release will be pretty much RC2, with only minor changes (if any)?

The reason I ask is because I downloaded the ISO image today, and installed it on my HP laptop. It runs beautifully (as I have come to expect as standard on Slackware). I would like to know if there will be any major changes, such as the ones in between RC1 and RC2?

I think things are pretty much nailed down at this point. :)

Everything looks good here, running on 2 different machines.

Hi,

Please upgrade usb_modeswitch if possible. It's still at version 1.2.4, while some new modems requires latest 2.0.1.

Thanks

Cool. I look forward to 14.1's imminent release.

Current is running perfectly here on two desktop units and on my netbook. :)

There is a Mesa bug fix release 9.1.6 -> 9.1.7.

-current running smoothly here - x86_64.

RC2 doing fine there. Testing still under way with Xfce and Fluxbox...

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
[..]

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?

If it's an easy fix, it would be nice to have locale(1) and localedef(1) man-pages please. It's not a new issue as they've also been missing in previous releases. I'd assume that they'd come out of the glibc build somehow, but for whatever reason it seems we don't get them.

I just had a quick look and no man pages come from glibc they come out of man-pages from kernel.org and the latest (which we are only .01 behind) doesn't even have it.

A web search comes up with one and the copyright notice on it indicates that it originated in the Debian project.

Thanks wildwiz. I'd noticed they were in other distros so perhaps they've all borrowed them from debian.
Looking at the glibc.Slackbuild it doesn't look like the first time this sort of things has had to be done:

I asked Denis Barbier if he knew where to find recent versions of man (1) locale* and he answered:Tanslation in English:

Just a follow-up on the hardware clock thread that might be worth thinking about for release.
http://www.linuxquestions.org/questi...9/#post5050319

Thanks Didier. I've worked out what I needed to know:
localedef --no-archive -f ISO-8859-15 -i en_GB en_GB.iso885915

I just hate missing man-pages, and it would have been a handy reference while I was trying to remember the syntax. ;)


P.S. I had worked through the glibc info pages, but yes, there was minimal information in there. Think I got there in the end though. :)

any special reasons for this permissions?

did not even know that these folders exists, but since I can not access them I know that I have them

Hello,

The same in /usr/doc/xfig-3.2.5c/{,html}. These bad permissions come from the source package :

--
SeB

Booting huge kernel on 64-rc2, I see:
Don't know how significant this warning is but I'm guessing it's being shown because of these config options:
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_UHCI_HCD=y

I suspect they either both need to be builtin, or both need to be modules to avoid this warning.

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...

How about this change to the SlackBuild:

--mancha

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 :-)

[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.

Oh but there are real changes!
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

even here ... :confused:

request: remove man-page-posix, add man-pages-fr
 

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

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

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.

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.

Request: please add man-pages-fr to Slackware 14.1
 

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".

Agreed. That way both versions will be available.

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.

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.

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

Can't connect to wifi through NetworkManager
 

[wrongly posted as a reply, opened new thread instead, sorry]

Wouldn't a donation be even better, as most of it would go straight to the developers? When buying the disks, a good portion of the money goes towards multiplying and shipping them.

Is it possible to add label / uuid support for swap partition in the initrd? This should not be much different than supporting label / uuid for the root partition.

just for the record, is the version of the manual slackpkg which is version 12.1 ....

forgiveness lords :rolleyes:

A very good suggestion. I will consider it for the next release.