SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Eric, my thanks for the update. I feel that having a standardised way of handling bridging in Slackware will be a big bonus.
I have already studied your guides on QEMU and VDE which allowed me to get a virtual machine running on my little intranet at work. I also wish to say thankyou on behalf of my colleagues! It has been a boon for productivity.
BTW, Anyone else notice Pat's use of "slackware-next" in the comments for the kernel package? Far more descriptive name than "slackware-current" which has always seemed a bit of a misnomer. I like it.
I saw that and wasn't sure how to interpret it. Does he mean slackware-current will be called "slackware-next" after 14 is released? Was he just using it a placeholder for "Slackware 14" (i.e. the next release number)? Or did he mean slackware-current after 14 is released, not to be confused with -current prior to 14's release?
I took it to just be a placeholder to mean "Slackware 14": "Systems older than that can still be upgraded to -current (or the next release of Slackware) and will work fine using megaraid.ko . . ."
Perhaps you're right, though at this stage he knows he's going to number it 14
Quote:
Bumped slackware-version to 14.0.
... so why use a placeholder at all.
Changing the name would require coordination with the mirrors and tools though so I wouldn't assume he's planning to change it unless he says so explicitly. It just struck me that slackware-next was a better name than slackware-current considering its role.
Speaking of networking: any chance of a bump for NetworkManager to 0.9.4 in -current? I've been using it with the associated bits and pieces (nm-applet, VPN plugins) for a few months on 13.37 and it works fine. It'd be great to see it in 14.
Maybe he wrote the note for kernel-huge before updating aaa_base and writing the note for it, then didn't go back and just say "Slackware 14" in the kernel-huge note. Either way, it's still a bit of a cryptic reference. I also considered the mirror problem of changing the name of current to "next". Probably unlikely due to tradition and inertia.
Maybe he wrote the note for kernel-huge before updating aaa_base and writing the note for it, then didn't go back and just say "Slackware 14" in the kernel-huge note.
That's exactly what happened. The kernel package was originally compiled on june 22nd, and we deciced only later on the next release version number.
The kernel is always first target, followed by glibc, when the gcc has been upgraded. The kernel packages were rebuilt just before going public with this batch, to add
Code:
CONFIG_FB_EFI=y
(it was off at first but I read a post by ruario yesterday, stating that this was needed to get visible framebuffer text on EFI boot).
I solved the problem in the hard way: recompiling the KDE-4.8.90's kdelibs and kdebase packages group.
And thank you, AlienBOB, for the excellent KDE build-system!
Thank you Darth Vader. And, good to see you're still using Slackware! I thought you had moved darkstarlinux away from its Slackware parent and were no longer slacking.
The kernel is always first target, followed by glibc, when the gcc has been upgraded. The kernel packages were rebuilt just before going public with this batch, to add
Code:
CONFIG_FB_EFI=y
(it was off at first but I read a post by ruario yesterday, stating that this was needed to get visible framebuffer text on EFI boot).
Cool, that'll should it much nicer when using EFI based systems, though I was really just repeating what rwebber had discovered.
Most of the packages have been updated, but not everything. While the base of 14.0 has been set, the real true remaining updates have yet to be made yet, such as the new version of XFce, the newest kernel, and various other library packages to name a few.
You can tell the next release is near, but it's not here yet. Plenty of work left to be done, so until then, keep your eye's pealed on the Slackware.com webpage and the Changelog.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
