Massive updates in -current
 

Must be close folks - "are we there yet"!

At least, we were never closer ;)

I suggest you to wait a little before syncing your mirrors, because it seems this time Pat hasn't used the --delete rsync flag to sync his own, so old version of the packages are still there.

And the /source tree still contains the old slackbuild files

I think the new release is very close, read the changelogs:

main mirror has just been fixed :)

Nope. Hold your horses, this is just a simple change in one file. It shows what the next version will be called.
Expect to see release candidates and other humdrum prior to an actual release.

Eric

osuosl mirror still outdated. Its not quite good because Slackware.com/Changelog links to it.

UP: Forgetting it. Waiting for RCs.

if you want an updated rsync mirror, try carrol: pass to alien's sync script this variable

RSYNCURLROOT=carroll.cac.psu.edu::slackware/

Goody I like updates! :)

Seems fine here, the old packages seem to be gone as ponce says.

BTW You do know that ftp.slackware.com is ftp.osuosl.org ?

Nice set of updates, especially for KDE fans. I was hoping to see some XFCE bumpage, but I've waited this long, I can wait a little longer. :)


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 will wait for my local mirror to sync, but I am curious about this.

From the new rc.inet1.conf file:
Setting up a bridged interface will be helpful to get a virtual machine connected to the network. For some scenarios a bridge works better than a NAT solution - a bridged network connection will allow your VM's to be accessible from the network so that you can run network services inside the VM.

See my rc.vdenetwork script for an example of how to setup a bridged configuration which uses VDE to connect virtual machines (QEMU in my case) to the LAN.

This is the configuration I use to build all my packages.

Eric

I really appreciate the built-in bridge support in rc.inet1 - it'll replace my own, probably brittle, shell script implementation. Thanks, Eric :)

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.

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

I quote all of this :)

It seems that rsync.osuosl.org has just been synced. Thanks

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.

People running my KDE 4.9-beta2 for Slackware-current, please note that the upgrade to attica-0.4.0 in -current broke a great deal of my packages.

Read http://alien.slackbook.org/blog/test...kde-4-9-beta2/ if you need a fix.

Eric

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

Eric

Too late! :)

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.

Cheers, Eric

Thanks for the quick fix Eric!

Should have come here first before upgrading, but it was nice to use lynx once again ;)

Cheers.

Cool, that'll should it much nicer when using EFI based systems, though I was really just repeating what rwebber had discovered.

Edit: Offering an EFI capable bootloader would also be nice.

P.S. If anyone wants to test EFI booting and doesn't have the hardware, VirtualBox can simulate an EFI system as rwebber also pointed out.

Upgrade went smooth as silk today. Many thanks to Patrick J. Volkerding and the entire Slackware Team. It is all good, man. :)

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.

The best is yet to come.

libgpod has a mistake - it contains /usr/lib64/pkgconfig/libgpod-sharp.pc.

But you have built gpod without sharp support. So the .pc-file should be removed or the package rebuilt with gpod-sharp support.

I would like to have the second, I could remove one dependency for my banshee packages then :)

Edit: Upgraded all packages now. Worked flawlessly. As always. A stable rolling release is a nice thing to have. :)

The kernel was just updated to 3.2.21, which is the most recent long-term stable. This seems like a sensible choice. What makes you think they would jump to 3.4.4 or later?

The Linux kernel has been evolving quickly adding new drivers and support factors at a fairly rapid pace. Now, I would say that the 14.0 branch might stick with the LTS Kernel, but Patrick has been known to add a different and often newer kernel and into the /testing directory each release, or include a .config file in the /source directory to build even later versions if they work well.

The thing is, nothing at the moment is completely finalized so it's all speculative, but as a general rule, follow previous releases and you can often get somewhat an idea of when a release will come, and also what may or may not be included with that release.

@ReaperX7: Sure, it is quite possible he might add a newer kernel to /extra but I read your comment to imply that the primary kernel number might be bumped again and I think this is unlikely, unless the Slackware 14 release turns out to be a long way off.

Just a question: do you have noticed this line in the Changelog.txt?

Do you have any clue of what it is about?

that was discussed a little here at the beginning of may

https://www.linuxquestions.org/quest...ml#post4671085
https://www.linuxquestions.org/quest...3/#post4671080

seem that "the future is now!", as the libffi package was added to -current with the same update ;)

Just finished rebuilding additional packages depending on Python, everything went great. Thanks to Pat and the crew for this nice batch of updates!

I have one question though: mercurial's doinst.sh.gz contains the following two lines:
Can someone enlighten me about the reason behind the last line? Is this intentional or simply a leftover from some tinkering with the code?

I'm with you on this one, It doesn't look right does it.

Just updated. Looks like the new kernel 3.2.21 still doesn't build brcmsmac (which eliminates the need for building broadcom-sta on many laptop wireless adapters I use.) I reckon it didn't get built due to a Kconfig bug in 3.2.13; hopefully it gets into the next kernel package revision.

As to gcc, why are there the "source/d/gcc/gcc-4.7.1-x86_64-1.txz" and other pre-compiled package files under the source directory?

I noticed them too during sync, the x86_64 packages are in both source (32 and 64) trees, maybe they will magically disappear with the next update ;)

I bet that they will. ;)

Talking about x86_64 packages present in slackware-current...

Looks like aaa_base-14.0-i486-1.txz now contains the /lib64 , /usr/lib64 and /usr/local/lib64 directories, which I believe are specifically to x86_64.

Still, the source/a/aaa_base present the right build.

I am a new slackware user, since june 3rd and i have never seen so many upgrades on any linux distro i have ever used in as short a time span and i have been using linux since about 96. The really amazing thing to me is not just the massive number of upgrades, but core stuff as well, and nothing so far has broken. Im a bit incredulous :)

I have been checking the upgrades to unmark the kernel (i like to build my own) and the x stuff i dont need and anything that might be dangerous, but i was a bit perfunctory in checking the latest list and after it started i saw glibc go by and thought "uh oh, that could be a problem" and after rebooting everything just worked.

Before i installed slackware i checked out the wiki page and other sources and it seemed to have a bit of a stodgy rep. Given the number of upgrades i have seen and its continued rock like stability, I have no idea why this is, unless maybe that its the oldest distro around. This seems to me entirely undeserved, im just totally impressed.

Anyway, hats off to PV and company :)

I find it slightly weird that updates make me more happy than cake...

don't worry mate...

as long as they do not make you more happy than a girl

Hi,
any news on this subject? What do you people think?

Hi, the config() handling of hgk.rc.new is there to let people comment out an optional feature without every package upgrade to mercurial enabling it again.

I don't think it's the config() handling that is at question here Pat. It's the rm outside of it.
- If old doesn't exist move new to old
- else if new and old are the same remove new
- else leave it for the admin to sort out
- but then it gets deleted anyway outside of config(), so the admin will never get to see it.

That comment in config() is just part of the boilerplate... in this case the file is not expected to change.