The upcoming release of sbopkg (0.30.0, I think) will include a set of sample queue files to do just this. I've submitted a few to the development team, as well as the 6 or 7 they already have. Thus, if you install sbopkg with the next release, you'll get a bunch of queue files to build some complicated packages.

If you're feeling that way inclined, you could write some yourself and submit them, they're not particularly complicated. Here is a monster one for all the multimedia-type applications at SBo:Options to pass to the build scripts are separated from the package name by a |. Packages can be omitted by prefixing them with a -. You can also call another script within a script using the syntax:In addition, a new switch (-k) added to sbopkg in SVN means that any packing which is currently installed can be skipped (no check will be made to see if there are any updates to this packages though). So, calling sbopkg as follows will build and install all the packages in the sqf file, but will not re-build packages already installed on the system:This functionality is not available in the ncurses-based menus.

This is actually not necessary -- libdvdread does a soft dlopen() for the libdvdcss libraries, so simply installing libdvdcss is enough.

Ah, that's handy

I'll let chess and the gang know and they can modify the queue file to reflect that.

As an aside, I was trying to build dvdbackup last week and noted that the version of libdvdread (Mplayer's, as opposed to Ogle's) in -current won't allow dvdbackup to compile. There is a patch on their site, which when added to the SlackBuild for current's libdvdread will allow dvdbackup to build.

I don't know what the policy on including patches in stock packages is when those patches aren't necessary to get Slackware working, but thought I'd mention it nevertheless.

I was tempted to email Pat, but thought he's probably got enough on his plate at the moment.

I *seriously* doubt he'd apply a third-party patch to libdvdread for that. One never knows though :-)

That's what I thought, and why I didn't bother him about it.

It's easy enough to recompile libdvdread to include the patch, so I think I'll leave it at that

I stopped using KDE and basically all of this KDE4 nonsense. This isn't a Slackware thing, I just don't find KDE4 stable/usable/et cetera. Personal preference.

Additionally, I have found myself on a slower computer because my old one is currently broken. Occasionally I have the need for a word processor and I very frequently have the need for a basic, but not rudimentary, spreadsheet program.

I turned to my old friend siag, which I propose should be included even if it is trivial to compile.

Sorry for two edited posts in one thread, this one was due to a misfire on "submit reply". I'm on a laptop with broken keyboard/touchpad.

Jacob

I under stand what your saying. I finally took my old 1200 mhgz machine and passed it on. I have a dual amd core 2.8 ghz machine with 2 gigs of ram.
KDE4 is very stable on slack64 I find it very simple and many tools for navigating.
there is just an endless amount of personnel set ups.
I have to agree that the old machine made the big ram eater KDE4 lethargic but never unstable in slackware.
I go back and forth with KDE3 and KDE4 after some use I find kde4 is really growing on me. Just MY Personal preference

There seems to be a wide gap between the "it's stable" and "it's completely unstable" crowds. My guess is that those who find it unstable have a need for some rather particular functionality. I have no doubt that these will eventually be cleared up. Additionally, some apps have yet to be ported to KDE4 or have ports in a very alpha state. Again, I'm sure it'll all be cleared up. It just comes across as completely unusable when things start crashing without any explanation after 30 minutes of usage.

What sort of bugs? Kile, for example, crashes when I try to do certain search/replaces with regular expressions, but hey, vim+vim-latex is much better anyhow. Or, for example, I recently discovered that kopete crashes immediately when trying to configure a webcam (4.2, 4.3... across distros).

Even when it's stable for me, I just don't like it (e.g. dolphin). Some people don't like tomatoes --- it's pretty much the same sort of dislike. No matter, I'm currently having more fun configuring my own desktop solution --- so no worries.

Jacob

I would like to see a little more suport for webcams.Suport would be just a little more updated info in Documents. The kernel keeps changing and the drivers are becoming part of the Maintained kernel. . this crash is actually a 64bit problem I have with slackware it is not a KDE4 problem. If 32bit grab the package at slackbuild.org and install it and edit your launcher to preload the v4l1compat.so. for 64bit you need to get the source and I install it to default /usr/local/lib/ because I just want to keep it seperate from my other stuff. I use amsn and gyachi and I launch them like this. this loads the /usr/local/lib/libv4l/v4l2convert.so library that converts v4l1 to be used worth the v4l2 driver that comes with the kernel.

Gap indeed,


Some interesting observations:
1. krandr has to be loaded in the task tray to keep your settings for external LCD's.

2. KDE developers have yet to implement the background effects like blending in plasma.

3. Even with desktop effects disabled in KDE4, OpenGL performance suffers on my system.

4. CPU Frequency scaling is broken for Sony laptops, don't know about the rest of you guys. Had to manually set /sys/..../cpu0 and cpu1 to Performance. Which brangs me to another issue on the intel front. Prior to xf86-video intel 2.8, there was a bug with cpu scaling crippling performance. You'll get this in 2.7.x.

I wrote something like the following in another thread, but now, looking at the system upgrading to JDK 6u16 and thinking if I should stay on -current or go 13.0, I guess it may be worth the effort to restate it here.

There are packages that I believe are very much out of Slackware control being developed by well respected upstream teams, like Sun JDK, Firefox, Ruby, Python, PHP, and so on. Currently the latest versions of such packages appear either in -current or on Slackbuilds. I guess it would be nice to have them in /extra of the stable branch, at least those that appear in -current anyway (that is, JDK and Firefox but not Ruby 1.9 and Python3).

My humble guess is that this may require a change to slackpkg so that it knows when to use a package from /extra and when from the main tree, while creation of the packages can be automatic and just a side effect of compiling them for -current.

It is not necessary to test such packages since if there are problems they should be considered upstream problems, not Slackware ones. Slackware does not create JDK or Firefox patches, it just packages "as is".

Currently, as far as I can see from the change logs, 12.2 has Firefox 3.0.13 while -current has firefox 3.5.2; 12.2 has JDK 6u11 while -current has JDK 6u16. In plain user words, -current is current and stable is outdated.

JDK is a perfect example why this is not OK. The practice I commonly observe whenever Java is actually in use is to test existing software with each JDK release and, based on the results of the tests, upgrade or stay. That is, there is no "right" JDK version that should be included with a distribution and it is not correct to say that 6u11 is in stable since it is well tested while 6u16 is not well tested and thus is only in -current.

it took me a while to figure this out
but now whenever I install a new version of slackware
that's the first thing I do:

set the display:normal as default for html and tex files
in the elvis config files

I don't like this behavior a la emacs.
vi is an editor, period. I use it to edit code so I expect
to see my code there.

Hope also we'll have alternate window managers. I don't
intend to use kde4.*

Firefox and JDK are easy drop-in upgrades, so there is no point in putting a newer version in /extra after a release. Just download it from -current (or use the SlackBuild) and upgradepkg.

They're in there

Yes, it is not hard. There are no hard things left with Slackware and this makes the "it is not hard" argument, regardless of the issue, invalid (obsolete?). The first 3 possibly valid arguments that come to mind are "there are other things to do", "Slackware users should never desire that", and "there are unwanted side effects".

Firefox may be the easiest to handle. Currently, there are 2 options for stable - allow Firefox to upgrade itself and get it in /opt out of the slackpkg reach or repackage with slackbuild and hope that creative Firefox people did not add a change that breaks the process. Isn't getting Firefox with slackpkg easier? If upgrading to /opt is OK, why does the firefox package exist?

Exactly what I propose had been done to KDE and is being done now to the .30 kernel. The idea is to extend the procedure to whatever possible.

What if future slackpkg will have kind of functionality currently offered by utility named tracepkg?

It wouldn't go against slackware principles. Wouldn't it?
(Just a thought.)