Observation of Feb -current vs March -current
(Please note: This is not a slam at -current... I think -current itself, and the concept is awesome, and I would like to keep using it. This is more of a whine for advise or tips, clues, etc before I slackpkg to the current -current. :] )
I'm fairly new to the whole -current experience, but I'm still n00b enough to not understand why certain things aren't compiling or even working.
Two months ago after a small amount of gentle guidance (almost painless), I had the -current up and running with no problems that I had noticed - except that I still haven't bothered recompiling 126.96.36.199 or even getting "generic-smp-188.8.131.52-smp" working.
The whole ~01 March update came around (after the 30 days no activity), and that's where things went downhill for me.
Initially, I was unable to recompile the driver for my modem, but some kind FreeNode ##Slackware user gave me the fix (some ln command ... I wish I had saved that somewhere.)
Since then, some other observed problems;
- [Solved] Cups no longer saw my usb printer. Blacklisting the usblp module fixed that.
- digikam lost its ability to view images. I recompiled, tried installing the alien version, etc - no go. The app would load fine, show the thumbnail versions of images, but trying to view the large version would result in an unsupported file type. Gwenview, etc would show the images just fine.
- Aptana would no longer load. Although it's not exactly perfect, it had not even crashed in the last few months.
I could not install many sbopkg packages, including bluefish, amaya, keepass. They would fail after a large quantity of compiling had completed, yet there was nothing useful (to me) as to why.
Today, I restored my root (/) and boot (/boot) image from Mar 2nd, back to 184.108.40.206-smp, and again I can install packages, view in digikam, etc.
So, any pointers where I went wrong? Other than that one 'ln' I performed (which allowed my modem to recompile), I had not messed with any libraries, kernel, etc. Could this somehow be related to that --without-gmp (coreutils) problem?
Other than reading the changelog, and trying to keep up on this forum - are there any -current specific guides, pages, forums, etc?
(Again, this is not a complaint. I did heed the warning - the only system I play with -current on is one I am willing to wipe if needed.)
First off, current should be considered as slackware beta, things will break. Typically people run current to find problem to help with the next release. Or, like me, it give us something to fix on Slack. The stable releases get boring after the first few weeks.
Second, if you are going to be running current make sure you do a full system backup before a major upgrade. As a matter of fact, before any upgrade.
Third, search, search and search some more. There is someone else out there experiencing a similar problem to yours and may have a solution or started the leg work.
And Fourth, read the change logs. It will help with your upgrade or with fixing problems. I don't think there are any other guides around.
Then there is the forum and IRC. Logs of the problem you are having is always good. Compile errors are usually very descriptive on what went wrong. If you don't understand the error message, someone else will be able to help.
I will agree with you that March current has been nerve racking. I personally lost X and mythtv on my HTPC. I found a solution for the myth but none for X. For now, I have blacklisted X in slackpkg until I get some time to figure it out.
If you're not prepared to do a little leg work then why not just stick with stable? I guess the updated KDE is the culprit but -current really isn't meant for people who don't know how to fix things when they break, and I am strongly opposed to additional documentation being created for -current since that takes away the time of people who could be contributing to -current to eventually make a solid stable release.
Most of your problems appear on the surface to be related to the libpng upgrade. digikam would have to be recompiled against the new libpng, as would most apps that use libpng to display images (that's basically any third-party graphical app that you have installed that uses graphics). The specifics of your compilation woes cannot be determined without more information (like error messages for each package), but some of them may need to be patched to compile against libpng 1.4.x (or the latest SVN/git/whatever build may already support libpng 1.4.x and you can simply compile that instead of the version supported by slackbuilds.org). The compilation error could also have something to do with glibc/gcc or something but if you are able to compile some things then that is likely not it -- but again we would need to see the errors.
About sbopkg and Slackbuilds.org problems -
SlackBuilds.org only maintains build scripts for stable releases of Slackware. Many of the current build scripts will have issues because of the upgrade to bash - which has been in testing for some time and is available on 13.0. Though the SBo maintainers have addressed the problem already with posts on the mailing list, an added FAQ and a change to the sample template. Bash in testing Some bash changes
This was a major overhaul and upgrade to the Slackware base. I feel for Pat and the team, they must be mentally drained. The amount of work I can only imagine that went into this update and have the results on par, and mostly better than, other projects with 10 fold the man power, makes me wear my Slackware swag with pride :)
The best way to combat problems are honestly, this forum, IRC, mailing lists, and ... Google ;). If a particular application is having problems, check the upstream website. Most applications have bugzilla's, forums, and mailing lists. Mailing lists are perhaps the best resource. With Gmane and Pan, I can read posts to some mailing lists all the way back to 2002. If you're looking for patches, there's 3 patch happy distro's I look to. Debian, Gentoo, and Arch. Gentoo and Arch tend to follow Slackware's style in only patching when necessary. Add to that, some packages hit Arch's repos before the dev's even update their own websites. Of course disgression needs to be applied here. Sometimes, just waiting a day or two for upstream to officially release, or for the team to come up with a better solution is all it takes. More times than not, I believe I've found a bug, tested a fix, got ready to make a post/email, only to check the changelog to see they already took care of it in a better manner.
Once you've used Slackware for a while, you'll get a feel for it. Get to know Slackware by reading all of the txt files in the top level directory, the slack-desc's, read the SlackBuilds in the source directory. They are well documented, even quite comical at times. This is one of the better aspects of Slackware - the documentation is clear cut and simple to understand. Read your mail - Pat sent you a personal email after installing Slackware ;)
I'm glad that someone at least reads the documentation - I did heed the warning - the only system I play with -current on is one I am willing to wipe if needed Kudos to you on that part :p
Current can suffer a lot because of a lack of quality control upstream. The k3b bug I posted about last night being a prime example. Quite how such a blatant fault like that went out in what KDE call a "KDE SC RELEASE" without being found during testing is... Well, clearly they just don't test properly.
In contrast Slackware is heavily tested by the time it is given a tag of "RELEASE", and current is where it gets tested, and we, the brave and foolhardy Currenteers are the testers.
Running current, you will feel pain at some point or another, but the more folk there are running it for day to day tasks the more bugs will show up and the better the release will be when it finally gets here. Having said that, if someone is running current when their skill level isn't really up to the job, then it only results in additional work for the Devs filtering out the self-induced/false bug reports.
If you don't feel entirely comfortable riding the crest of the the wave but you still want to follow current and help test, then the simple solution is not to apply everything the day it is released. Use your brain and if a lot of significant changes appear, leave them a day or three and watch the forums for reports. Anyone who didn't expect problems with the March 1st mass-update really needs to think a little harder about what they are doing.
Personally, I wouldn't go anywhere near a tool like slackpkg for the purpose of following current. Instead, keep a local rsync'd mirror of the current tree and update from it manually. And as others have already mentioned, "backups, Backups, BACKUPS!"
Slackware-current is... well, slackware release in progress, so you can't really expect quality control and improvements only. When something gets updated, things might brake. At the -current stage, it's important to keep the things up-to-date, and not to keep them super-polished.
Living on the edge with '-current' is just that: 'Living on the edge'.
I would suggest to the OP if '-current' is just a taste or sampling then why not just work intermittently via a VM or dual boot. That way your system won't get borked if things go wrong. If you don't actively participate in testing, breaking your system to provide feedback then the question is to you. Why are you using 'current'? Bleeding edge? If so then at some point in time you will bleed.
Stick with 'stable' and upgrade.
I appreciate the rest of the positive feedback and suggestions so far...
Backups: I perform the regularly, and especially before a significant upgrade or change.
For the 'March 01' burst of updates, I did indeed wait a couple of days.
disturbed1 - Thanks, you've given me some good starting points (and reading material) on where to go from here.
GazL - I've seen the rsync / local mirror concept posted before, I'll check that out. Are there any recommendations for scripts that perform this and notify me of changes? (I've seen a few out there but rsync didn't work with the mirrors I tried, and I think I ended up using lftp.)
onebuck - The more I think about this, the more I like your VBox idea. I'm also thinking of keeping another few partitions for dual boot (one stable, one current). The learning curve on 'current' is (obviously) a major step up compared to tweaking 'stable', and this (combined with having the latest version of some of the apps I use) is the lure for me. I want to learn, and I am willing to get a few bumps and bruises in doing so, and the VM / dual boot method may be right for my (low-ish) level of experience here. :]
Until about 2 months ago, my personal PC was WinXP (with occasional attempt at Slack) and I had a headless Slackware box acting as a play server, web development, email, etc (which is what I've done for about 10 years now). I had followed many how-to's, and gotten some interesting things working - raid, luks/crypt, but not the coffee maker yet ;] . I wanted to learn more about Linux/Slack and so started using it more on my personal PC. I made a list of things I used windows for (apps, hardware), and one by one got them working with the exception of TomTom. In the last month, I think I've booted windows up only once, and that was to perform an export of data from an app to use in Linux. Perhaps I jumped to current too soon.
The usual mirror script that gets recommended is Eric's
Not every mirror runs a rsync daemon so you'll need to find one in your part of the world.
I'm a noob: the only reason for me to ever run -current is to blame it on -current when things go bork. For the time being I'm stupid enough to run stable; I can only blame it on myself.
*thanks for testing!*
GazL - thanks for that, I've add it to my notes and will check it out.
(As I said from the start ... no blame here, other than my own lack of knowledge.)
I've almost learned as much about Linux/Slack in the last two months as I have in the last 10 years. Well, maybe not, but the curve has definitely gotten steeper.
Hi there ppl
when will we have a <stable> with a "nice" KDE ? A.K.A. Slackware64 13.1... ? :)
This place may have a better answer
Alex, I think I get what you're asking. Asking "when" tends to make people think you want the date, and the answer is always exactly what you just got. A better way to ask the question, since time/date is never known -
What's the roadmap look like for incorporating versions of KDE >4.3 into Slackware? What work has to be completed before Slackware can use 4.4 and beyond? Is it work that can be completed by the Slackware team independently, or are they (and we as a community) at the mercy of the large commercial distros that are forcing the *Kits into the Linux desktops?
It's becoming clear to me that 13.1 (whenever it is released) will use 4.3.x, and not 4.4.x. Will the Slackware release after 13.1 (be it 13.2 or 14.0) have 4.4.x (or 4.5, or 4.6), or will we be stuck in 4.3.x limbo indefinitely?
I'm not satisfied with 4.3 - some basic file management functionality is missing in Konqueror, among other things. So even if all of its bugs are worked out and it's 100% stable, it just isn't complete enough for me to want to use it. The features I want are available with 4.4, but I don't want to put it into production use using unofficial packages. If I'm going to have to wait indefinitely for a stable Slack with KDE 4.4 or greater, then I'll just cut my losses now and start learning and using Xfce.
Didn't mean to be picky about "when" ( kind of which day, month etc. )...
I know there is a great deal involved in porting the last Kde to Slackware... stuff like polkit, and other that can "break" slackware "philosophy" of development...
My question was based on the perception ( correct me if I am wrong ) that the incorporation of Kde 4.2.x into a "Stable" release ( considering the overwhelming weight of the concept "Stable release" in the Slackware community, reliability, fail-proof... etc ) was a bit of a precipitation... Slackware 12.1 and 12.2 are deemed ( by what i can grasp in the forum, although I never used them, I need support for 4-8 Gb Ram, which means 64bits, before Slackware I used Debian ) as much more bug-free than Slackware 13 <stable> ...
Once more the last words deserve a bit of a corection... :
It's not me saying Slackware 13 <stable> is buggish ... : it will perform flawlessly IF U DO NOT USE KDE 4.2.x... so, it's not Slackware that is to blame, it is Kde 4.2
This was the context of my question about Slackware [next] and Kde 4.x.y...
|All times are GMT -5. The time now is 11:12 AM.|