XBMC 12.2 installation problem - Oracle JDK installation

[gapan]

Try sourcing the file instead of running it:

Code: Select all

. /etc/profile.d/openjdk.sh

[rrttdd]

Yeeaah, managed to install xbmc!

But it was quite a mess!

After destroying my $PATH setting by testing and probing, I decided to add the java path manually by typing

Code: Select all

expand PATH=*binblabal*:/usr/lib64/java/bin:/usr/lib64/java/jre

This didn't work for the xbmc 12.2 slackbuild of the salix repo, but it worked for the 12.3 slackbuild of slackbuilds.org!
In principle...

-The xbmc 12.3 slackbuild couldn't find the taglib 1.7.2 I had installed before using gslapt and the Salix repo. --> I had to find a taglib 1.8 slackbuild in the www, and this problem was solved.

-The xbmc 12.3 slackbuild of slackbuilds.org requires Samba 4. The latest version within the Salix repo is 3.6.8/3.6.20 --> so I downloaded a Samba 4 slackbuild, which took a looong time to create and install. After another loong period of time finally, the xbmc 12.3 slackbuild was installed.

*Phew!*



My impression is that the Salix OS project urgently needs some people for packet building... If you have a "project" in mind you want to realize with Salix, and you need additional libraries and packages, you'll suddenly recognize that

a) many important packages are slightly outdated

b) many packages even don't work

That can be quite frustrating. I needed several hours to install xbmc. In theory, I should have needed just some clicks in Gslapt...

Summary and to-do list for the package maintainers:

1) The Gslapt-Slackbuild of the original Oracle JDK 7u45 in the Salix repo can be removed or should be updated, since it refers to a download not offered by Oracle anymore
2) Something is wrong with the taglib 1.7.2 Gslapt-Slackbuild in the Salix repo, since it couldn't be found by the xbmc 12.3 slackbuild script. Furthermore it's outdated.
3) The xbmc 12.2 slackbuild in the Salix repo is outdated and can't find any JDK.

Perhaps someone finds the time to test and fix... Unfortunately I'm not skilled enough. I can just try to solve my problems by applying transferred MS-DOS/WINDOWS 3.1 DLL hell / Turbo Pascal knowledge to Salix... (Indeed, it feels a little bit like optimizing AUTOEXEC.BAT to get conventional DOS memory for a new game in 1992... )

Nevertheless, Salix Ratpoison is the best Linux distribution for me. I started with 13.37. A few months ago I upgraded the laptop with a ssd drive, and the urge to re-install Salix RP has been growing stronger and stronger since then... I think it's great to have a distribution which doesn't try to copy the Windows experience and messing up packages and confg files by automated assistant tools.

[mimosa]

I'm glad you're still bitten by the Salix bug!

Regarding the points you raise - which recall some other recent discussions here - first, you're absolutely right that more packagers would be a big help. Testing is also hugely important, the more testers the merrier, for example with the 14.1 beta. However, among Slackware-based distributions, I believe Salix has the largest respositories, meaning you get 500+ packages on top of vanilla Slackware.

Secondly, packages being up to date depends on each distribution's policy. There is an inescapable tension between having the latest version and stability, because if you upgrade one thing, it may break another. Salix, following Slackware, aims to provide a set of packages in its repositories that work well together; normally the only upgrades to new versions are when there is a security issue. However, everything is upgraded to the latest version on a new release. A rollign release model like Arch linux's, on the other hand, means things break all the time and users need to know how to fix them.

Given that, when you say some of the packages don't even work, that's rather concerning. Please let us know if this is really the case, and which ones. It's perfectly possible in the sense that testing is never complete, but it should happen rarely. Are you sure you don't mean things from src (Sourcery / slapt-src)? These are a different kettle of fish altogether, as is anything whatsoever that comes from beyond the Salix / Slackware repositories. It's perfectly normal that some tweaking should be needed to make it work. This is the process that a package goes through before being added to the repsotories, which is why those *should* be expected to be reliable.

[gapan]

This didn't work for the xbmc 12.2 slackbuild of the salix repo, but it worked for the 12.3 slackbuild of slackbuilds.org!
In principle...

Impossible. Simply because what is in slackbuilds.org is in the salix "slackbuilds.org" repo that you get with slapt-src/sourcery. So it's impossible that one version is available in salix and a different one in slackbuilds.org. Unless of course you are talking about different slackware releases... You have salix 14.0 installed and you're referring to the slackbuilds.org 14.1 repository. But slapt-src/sourcery points to the slackbuilds.org 14.0 repository.

-The xbmc 12.3 slackbuild couldn't find the taglib 1.7.2 I had installed before using gslapt and the Salix repo. --> I had to find a taglib 1.8 slackbuild in the www, and this problem was solved.

taglib 1.8 is in slackware 14.1, taglib 1.7.2 is in slackware 14.0.

-The xbmc 12.3 slackbuild of slackbuilds.org requires Samba 4. The latest version within the Salix repo is 3.6.8/3.6.20 --> so I downloaded a Samba 4 slackbuild, which took a looong time to create and install. After another loong period of time finally, the xbmc 12.3 slackbuild was installed.

samba 4 is in slackware 14.1, samba 3.6.x is in slackware 14.0.

So all these are a problem of you mixing different slackware/salix releases.

My impression is that the Salix OS project urgently needs some people for packet building... If you have a "project" in mind you want to realize with Salix, and you need additional libraries and packages, you'll suddenly recognize that

a) many important packages are slightly outdated

b) many packages even don't work

Your impression is based on the assumption that slackbuilds.org is operated by salix. It isn't. Salix just provides some tools to interact with slackbuilds.org. If what you get from slackbuilds.org is garbage, that is not the fault of Salix or any of the tools that we provide.

That can be quite frustrating. I needed several hours to install xbmc. In theory, I should have needed just some clicks in Gslapt...

For packages that are available in gslapt, it only takes just some clicks. But xbmc is not available in gslapt, is it?

1) The Gslapt-Slackbuild of the original Oracle JDK 7u45 in the Salix repo can be removed or should be updated, since it refers to a download not offered by Oracle anymore

You see? Oracle jdk is not in the salix repo at all! It's in slackbuilds.org.

2) Something is wrong with the taglib 1.7.2 Gslapt-Slackbuild in the Salix repo, since it couldn't be found by the xbmc 12.3 slackbuild script. Furthermore it's outdated.

Nothing is wrong with it. xbmc 12.3 (from slackbuids.org 14.1 repo) doesn't work with taglib 1.7.2 (from slackware 14.0). Nothing wrong with that.

3) The xbmc 12.2 slackbuild in the Salix repo is outdated and can't find any JDK.

Again, that is not the salix repo. It's the slackbuilds.org repo.

[gapan]

However, among Slackware-based distributions, I believe Salix has the largest respositories, meaning you get 500+ packages on top of vanilla Slackware.

Make that ~1000 and you'll be closer to the actual number. For the record, slackware itself alone only provides ~1250 packages.

We need to make it clear in the startup guide that slackbuilds.org is not operated by salix and that we are not responsible for anything people get from there.

[rrttdd]

Thank you for the answer. But I really was unable to install xbmc using the Salix tools. The Slackbuilds.org script for 12.3 worked after regarding the library version dependencies and getting Java to work.

I think this Java thing is something which should be documented for beginners somewhere: Most Slackbuilds which require Java expect the Java directories in $PATH. But when you start Sourcery, you have to log in as root, and Java is not in %PATH anymore...

The idea of making clear,that what you get by default in Sourcery is not maintained by the Salix team sounds reasonable to me.

On the other side, the Salix team always points out the Slackware compatibilty of Salix. And it's just frustrating if you can't get certain Slackbuilds you want working.

[mimosa]

Just to be clear, what you get in Sourcery isn't maintained by Slackware either. Anything that is, will work in Salix.

http://slackbuilds.org hosts a collection of user-maintained buildscripts that are intended to work on Slackware, but may well not. If they work on Slackware, they will almost certainly work on Salix; if they don't work on Salix, they won't generally work on Slackware either.

There are actually some exceptions to do with what it is assumed the user has installed by default. But by far the most common cause for failure to build SlackBuilds is missing dependencies or out-of-date scripts.

To repeat the main point: these build scripts are not maintained by any distribution, Slackware or Salckware-based. Just a community of users. caveat emptor.

Having said that, failures can usually be worked round by a simple tweak. It is worth searching Salix forums and, if nothing useful turns up, posting about it.

[laprjns]

Just wanted to say that I installed XBMC 12.3 using slapt-src and slapt-get exclusively along with openjdk. Yes there were several dependance issues that needed to be manually resolved, but as explained this is because Slackbuilds assumes that many dependencies are already installed on your systems. I believe that your java issue was because you did not log out then back into your user account after installing openjdk (or jdk). Or you could have source the script as gapan suggested.