That which could be fixed in SBo thread.

I am not getting those numbers wrong, because that is the number of slackbuilds I have installed on my system which I can personally verify do not need kde or xfce packages. 174 now including liebetpan and claws-mail. Yea, I understand the package sets are not related to isolation and it wasn't my intent to imply that, just that it does seem to work out that way when it comes to kde and xfce. I also agree that this thread is not for such errors caused by missing dependencies from a subset of a full install, but as a relatively new slackware user I'm not yet experienced enough to always figure that out to be the case, most of the time it is arguably more obvious. In the case of the jpilot errors, all I previously found with a google search was some old patches that didn't seem relevant and based on what I have heard in #claws I'm still not sure that missing kde packages was the issue here.

As for the jpilot config.log, its too long to post here so I attached it instead if anyone wants to spend some effort figuring it out. Both 1.8.1 and 1.8.2 fail with the same error.

Originally Posted by orbea I am not getting those numbers wrong, because that is the number of slackbuilds I have installed on my system which I can personally verify do not need kde or xfce packages. 174 now including liebetpan and claws-mail.

I meant that your own is just a setup, for others the numbers are totally different and in most cases where an user choose to install a subset of the stock packages there's more than just one failure building stuff from SBo.
when you say I "preach" (I hope it's not generally got this way, I'm just stating what's supported and what not) I am obviously referring to all, not just you.

going back to jpilot: where it fails there's this

/usr/lib64/gcc/x86_64-slackware-linux/4.9.2/../../../../x86_64-slackware-linux/bin/ld: warning: libbluetooth.so.3, needed by /usr/lib64/libpisock.so, not found (try using -rpath or -rpath-link)

$ grep libbluetooth.so.3 /var/log/packages/*
/var/log/packages/bluez-4.101-x86_64-1:usr/lib64/libbluetooth.so.3.13.0

so you most probably are missing bluez (it's in the n serie).

I repeat: please, avoid reporting issues in this thread if you are not running a slackware current full install.
if you are running a subset of the full install and you have building issues report only if you are *absolutely sure* that it's not related to local missing dependencies.
if you are not sure don't report errors.

Ponce can you check libcdio against gst-plugins-ugly? I had to actually uninstall libcdio from Slackware to use gst-plugins-ugly to build the plugin.

maybe you missed it, but has already been reported in this thread

https://www.linuxquestions.org/quest...ml#post5361238

Just to be clear I never meant you with that, only a few users have done such preaching and mostly in other threads (Often mentioning kde or xfce when they are not even relevant for the specific issue). And also you are right, with some further help from #claws the same conclusion was reached, I have previously removed the bluez package which pilot-link was compiled against. This leaves 3 solutions for claws-mail in addition to --disable-jpilot, reinstall bluez (Which I prefer to not), recompile pilot-link without bluez (This works) or just remove pilot-link (Which also works). Apparently 55020 was wrong about kde-pim which claws mail does not depend on. As for jpilot I was wrong in my guess that it might be a dependency and I pasted the error just because it was relevant to the discussion, not because I was interested in fixing it or using it.

To be blunt, avoiding reporting issues which are clearly related to missing dependencies in official packages is reasonable, but to tell anyone who doesn't have a full install to avoid reporting any issues just because there is a possibility they might make a mistake and report such an issue is just silly and does nothing for teaching that user or someone else just reading to not make such mistakes. What do you suggest, to make another redundant thread where that won't be an issue? In short, I (And hopefully some others) learned from this experience and I think that is what truly matters.

Originally Posted by ponce please, avoid reporting issues in this thread if you are not running a slackware current full install. if you are running a subset of the full install and you have building issues report only if you are *absolutely sure* that it's not related to local missing dependencies. if you are not sure don't report errors.

this thread is for grouping issues related to SBo's stuff that doesn't build on current because of the updated software there.
issues related to custom installs don't belong here: please for them open another thread, also if you are not sure if the error is related.
there's nothing to be fixed on SBo (to quote the title, not a happy one but yet...) if someone is missing dependencies from a slackware full installation (the only one supported by slackware and by SBo).
I'm saying this with no intention to be rude at all.

Originally Posted by orbea To be blunt, avoiding reporting issues which are clearly related to missing dependencies in official packages is reasonable, but to tell anyone who doesn't have a full install to avoid reporting any issues just because there is a possibility they might make a mistake and report such an issue is just silly and does nothing for teaching that user or someone else just reading to not make such mistakes.

http://slackbuilds.org/faq/#full

Originally Posted by orbea ... but to tell anyone who doesn't have a full install to avoid reporting any issues just because there is a possibility they might make a mistake and report such an issue is just silly and does nothing for teaching that user or someone else just reading to not make such mistakes.

I fully disagree:

• This thread's topic is "that which could be fixed in SBo". So posting anything in it that could be fixed just using the SlackBuilds as intended is clearly out of topic.
• This thread's aim is not to teach anyone anything.
• You certainly don't realize how much time valuable contributors like ponce have already lost because people wrongly complain something is broken, instead of first checking that they used the Slackbuild as intended.
• "is just silly" is disrespectful, especially coming from a newbie and addressed to a major contributor to Slackware and related projects.

Ponce's music recommendations are great too... listen and chill
orbea, I hope you'll stick around, everybody is welcome to be disrespectful to me any time, in fact I demand it

Originally Posted by chris.willing Could I suggest: mkdir -p build cd build -DCMAKE_C_FLAGS_RELEASE:STRING="$SLKCFLAGS" \ -DCMAKE_CXX_FLAGS_RELEASE:STRING="$SLKCFLAGS" \ -DCMAKE_CXX_FLAGS:STRING="$(/usr/bin/Magick++-config --libs)" \ That will bring in all the needed Magick{Core,++,Wand} libs in a version-neutral way (and seems a little more cmake-like too). chris

I was having the same issues in compiling digikam, this elegant solution solved it. Thanks Chris.

Originally Posted by ponce this thread is for grouping issues related to SBo's stuff that doesn't build on current because of the updated software there. issues related to custom installs don't belong here: please for them open another thread, also if you are not sure if the error is related. there's nothing to be fixed on SBo (to quote the title, not a happy one but yet...) if someone is missing dependencies from a slackware full installation (the only one supported by slackware and by SBo). I'm saying this with no intention to be rude at all.

Exactly. Testing against a custom install is problematic because we have no idea if you are missing dependencies or what exactly you customize after the fact, or from the install. It's more work we don't want to do.

Sorry, but to properly ensure every SlackBuild package works it must be tested primarily against a full install. Even my Slackworks projects rely on full installs, as do other public repositories.

You are free to start a new topic on a custom install issue, but this is a topic geared at getting SBO up-to-date and readied for 14.2's eventual arrival, and getting packages ready through the usage of -Current.

May be some idea of what builds on -current can be obtained from the SlackOnly repo. The maintainer started building packages for -current x86_64:

http://packages.slackonly.com/pub/pa...urrent-x86_64/

If this thread is about SBOPKG and the ability to stay in sync with Slackbuilds then discussing the program slackware build browser should what you want to talk about. As fo a person that keeps an fork of Slackbuilds you have to understand that when sourceforge is down for maintenance. Or many of the popular tar balls like ladspa_sdk that has been moved. or like gst-ffmpeg-pluggins that has actually not being developed but has been forked to what libav or somthing per the developers that maintain it. list goes on and on. up to you the individual to handle these problems.
These are issues that Slackbuilds have no control over. It is the individual contributors that need to check there sources.

As for Slackbuilds website the only thing I have issues with is the maintainers not checking to see if the repo of the source code still are on the correct server.
That is a maintainer issue. Take that up with the Maintainer. Or do like I do fork it and make your own.

Bump for keep alive as an ongoing thread against the other update topic.

Originally Posted by ponce that's because Robby's package is built on stable and you are on current. to let us try to help you please try again building the SBo script and post the full build log (on a place like pastebin). but it should be better if you open another dedicated thread as this is a issue pertinent to your installation and it doesn't apply to all current users: there's no libsecret-1.la in Slackware and building gthumb on current doesn't look for it in a clean full install.

Update: Yesterday I re-partitioned the HD and using an .iso dated 1-Oct., did a fresh installation of Slackware64-current. BEFORE doing anything else I was able to successfully build gThumb.
Out of curiosity, I tried it a second time after installing the NVidia driver and, once again, it failed with the libsecret-1.1a error.
Just FYI.