SBo scripts not building on current (read 1st post, pls)
 

the scripts that you can find on the official SlackBuilds.org (SBo from now on) repository are available for the latest Slackware stable so, in many cases, they won't build on current as they are provided.
if you need a repository that has patches to build them on current, please use this project (not supported or endorsed by SBo)

https://github.com/Ponce/slackbuilds

if you want to see the list of the patched scripts, there's also an alternative interface available at

http://cgit.ponce.cc/slackbuilds/refs/heads

this started years ago forking the SBo's repository as a personal effort to have a working queue available for the scripts Matteo used for his boxes but David's contributions made it something that aims to be a more complete aid to SBo users that use current on their machines: just don't expect that everything on SBo will be patched to work on Slackware's development platform as we don't want to do the job of every script maintainer and this project is a best-effort thing.

SBo supports building its own scripts on clean slackware full installation: we would go crazy trying to support any setup out there that we have not tested ourself for everyone of our 5000+ scripts.
this policy applies also on this humble, unofficial, attempt to let SBo things build on current.
following this it should be obvious that issues related to custom installs shouldn't belong in this thread: please open another one to discuss such things, also if you are not sure if the error you got is related but you are aware that your setup is a non-standard one.
describe your problem here only if you are absolutely sure that it has nothing to do with your custom setup.
there's nothing to be added in our repository for the benefit of other slackers if someone is missing dependencies from a slackware full installation or has stuff installed in /usr/local or has installed other third party non-SBo stuff that might be incompatible and so on.
there's no need to say it but if someone else don't agree with this policy and wants to support also non-standard setups is free to do it (but in another topic ;) ).

so, what is this thread for?
risking to be repetitive, report issues here only if you have already tried the scripts from our repository and they won't build on a clean and full installation of Slackware current.

also, if you want to report a problem that applies also to Slackware stable this is not the right place, this topic is current-specific.
if you think a script on SBo shows issues (broken download, not building, etc.) on such platform write to the maintainer and wait some days for an answer (a week should be fine): if the maintainer isn't responsive after this time please post the same thing by mail to the slackbuilds-users mailing list putting the maintainer in cc

http://lists.slackbuilds.org/mailman...ckbuilds-users

if you wonder how long someone does have to not maintain a package before it will be considered abandoned, the answer is that there's no fixed time: a package can remain at a certain version for many reason (compatibility, stability, lack of updates upstream, etc.) so the lack of an actual maintainer cannot be tied on how often it gets updated.
usually the package is considered maintained as long as the maintainer is responsive and supports his script so, maintainers, make sure the email address listed in .info file is valid and stays active.
for any other question regarding specifically SBo and not this fork refer to its faq

http://slackbuilds.org/faq/

Maintainers: if we have modified your script, our suggestions are not official! We hope that our suggestions will be useful when you do your official scripts for the next version of Slackware, or we will be very happy to accept your changes now :)

David and Matteo

P.S. Our repository is directly usable with slackrepo and sbopkg, see

http://idlemoor.github.io/slackrepo/
https://github.com/Ponce/slackbuilds...ry-with-sbopkg

if all you want is a local copy just clone it with git

For what it's worth, many of the updates to SBo when a new Slackware release is pending will come from this repo. :-)

I'd like to add that sbotools will soon(TM) get a new release which will be able to use your git repository as well.
There is a RC3 of it available as source tarball or as a slackware package.

You would enable ponce's git repo by doing
and then a sbosnap fetch or sbosnap update as appropriate.

If you have any problems with sbotools, please don't hesitate to open an issue.

Do note that this version is still just a release candidate, which makes it little more than a beta. It may of course contain a few bugs, though I haven't been able to find any so far.

note that, IMHO, the most practical way to sync, as the default branch of the repository is rebased always on the latest master from SBo's git, maybe is to delete the repository and then clone it again.

the alternative is using some git-fu.

You sir just made my Christmas that much better.

Having a -Current friendly repo for sbotools is appreciated beyond measure. Many thanks to you and ponce both.

So far, I've built most of the stuff on -current, relying heavily on ponce's branch (thanks, Matteo!). Only VLC is making trouble. I tried building 2.1.6 and 2.2.1, but without success. Since this isn't exactly high priority for me (I'm mostly running Slackware stable), I guess I'll wait until one of the more hardcore geeks has figured out how to build this beast.

Cheers,

Niki

I think this round you should thank mainly David: he owns most of the patches there!

"owns" the patches???? They're all just suggestions, waiting for someone else to test them ... or for the next big update to break them again :cry:

As I compile my VLC 2.2.1 package successfully on slackware-current I guess it is just a matter of applying the right patches. But without any backup in the form of compilation errors, I can not tell you what needs patching.

Thanks, Eric. I didn't think about your vlc.SlackBuild, since I didn't know it also worked on -current. I'll take a look at this, and if I don't succeed, I'll come back with a detailed error report. Will probably be in early January.

Cheers,

Niki

I do no Ponce does a great job the whole bunch do should throw a donation jar up there. That said freshplayer I have no clue why the dependencies are such. I do understand ffmpeg but it needs to be updated that version is broken with the latest pepper. That's a drop in the bucket
So much cool stuff in there.

freshplayer from there works fine here.

EDIT: I just checked and it seems freshplayerplugin had a new release yesterday: I'll have a look and if it's ok I'll update it in the repository.

FreshPlayer has quite a few dependencies, even from my testing of it. Ffmpeg, libconfig, ragel to name a few with pulseaudio as well as optional. Ffmpeg however is the biggest headache of the built though. Make sure you have a good deal supported by it though.

Just be advised that if you update any dependency of freshplayer it has to be rebuilt all over again or it won't work.

Re: vlc, it looks like all we need to do is mix and match Christoph's SBo vlc patches: http://slackbuilds.org/cgit/slackbui...multimedia/vlc

It builds, maybe it even works?
https://github.com/Ponce/slackbuilds...multimedia/vlc

Hello Ponce,

I notice that in dolphin-emu i have to keep setting the controller device every time i
run it otherwise the controller does not work.

I have no idea, sorry, I don't use dophin-emu.

try reporting the thing in the dolphin-emu forum

https://forums.dolphin-emu.org/Forum-support

I've had to edit several .info files recently after the files were added into the core of Slackware like libvpx, orc, libvdpau, and several others who have duplicates now in Slackware since sbotools parses them, but can not yet account for files in /var/log/packages.

This might warrant looking into since several of the sbo packages now are obsoleted.

Hi ReaperX7, I think you are not using our repository at all because the scripts you name had been removed from there since ages, see the branches list (linked also above).

I'm on your repo. However, some of the .info scripts have leftover dependency listings. I found one compiling nvidia-legacy340-driver for example.

ah, sorry, now I have understood what you meant.

no, I haven't edited all the info file removing the things added to Slackware from REQUIRES: I plan to do this, as usual, just on SBo's repo before whenever we're going live after the new Slackware is out.

sorry if this confuses some automated tools but, as you hint, it's true also that they should consider what's already in /var/log/packages.

Hello Everyone,

I can't compile conky in slackware current. I get the following error.

checking for Audacious... configure: error: Package requirements (audacious >= 1.4.0 audclient dbus-glib-1 glib-2.0 gobject-2.0) were not met:

No package 'audclient' found

Audacious is installed.

please see this commit on ponce's personal repository

Hello Willysr,

Nevermind i thought libaudclient was included with audacious.

hi GreenFireFly,

before installing a script from SBo or this unofficial fork for current you should first install the mandatory dependencies listed in the *.info file provided with the script (the "REQUIRES" variable): what Willy was trying to say to you (and that it's written on that commit he linked) is that in this repository we added libaudclient between the mandatory dependencies in the conky.info file as it has been splitted from the audacious version we have in current but conky still tries to use it.
so build libaudclient first: if you are using this repository you should find it avalaible in the libraries directory.

EDIT: I've seen you edited your messages noting that you have understood the point.

Several scripts like etm, nts and w3m complains about not finding libpng14, since current is upgraded to libpng16.

Hi Jostber,

If (for example) wxPython was built on 14.1, then naturally it will be linked to libpng14. Therefore, you always need to rebuild and reinstall *all* the dependencies after upgrading to -current. In particular, for etm, nts and w3m, you need to rebuild wxPython and imlib2, and maybe also libgnomeprintui, libgnomeprint, libgnomecups, libgnomecanvas.

The whole lot builds ok here.

OK, thanks, I will check that.

Ponce, check the following packages in the SBO tree (files now in the main tree that can be excluded in the .info files) and one has a buildtime error:

vdpauinfo > libvdpau
vdpau-video > libva, libvdpau (also refuses to build)
libvdpau-va-gl > libva, libvdpau

Error from vdpau-video:
I'll post more as I find them.

I don't know for sure, but I suspect that those are intentionally left as-is for now, because otherwise every version bump in the main SBo git tree would cause merge conflicts with the -current branch maintained by ponce. In other words, it would create a *lot* of extra work for very little gain right now.

Exactly, thanks Robby. I tried maintaining a private git branch to do the .info cleanups some months ago, but the constant rebase conflicts really are intolerable. Furthermore, there are some really complex renames to be done (e.g. Slackware's new fltk is the same as SBo's fltk13, so SBo's fltk is going to need a new name).

ReaperX7, really you had your answer in post #20 above -- your favoured sbotools handles this badly. slackrepo handles this properly 95 percent of the time ("No such dep in the git repo? Hey, if something with the right name is already installed, let's just go ahead and use that instead") and explicitly handles some of the complex package renames. I think sbopkg has some code to handle renames, and a related config file which might be helpful. Perhaps you could send suppy a patch so that sbotools can join the party, although really this is just a temporary situation, so whether such a patch is worthwhile is up to you.

As for vdpau-video, I have known about that for some time thanks. I think the same build failure also exists in 14.1 (in other words it's not specifically a -current problem), and with so many other packages to fix I've prioritised the low hanging fruit on -current. Perhaps you and the maintainer could come up with a solution?

Wow ReaperX7, it looks like Robby granted your wish -- there is now an official SlackBuilds.org 'current-wip' branch, Robby has worked on it for two days solid with just a couple of short breaks :eek: and one of the first things he did was to tidy up the .info files and READMEs ... it's looking good!

For avoidance of doubt, Robby's announcement on the Slackbuilds-users mailing list said: "This should not be read as an indicator that release is coming Real Soon Now" (you can read the whole message here)

I never implied a wish. However, good practices have the tendency to lead to better results. SBo is no exception.

I do not come in here to argue . But when I test something it is on a fresh full install. and then I go read the developers notes and how ppapi changed and thats why 1.3 is broken and why 1.4 is being used. I am glad 1.3 works with your version of flash ok. But read what and why the developers changed ok. Glad it works for you. I think I will stick to what they guy pushing the blob has to say.
Happy.

Don't blame the packager, blame the nutballs at Google who changed how PPAPI works.

Nutballs?
Please explain yourself.
Software APIs change all the time, and a program which creates a shim between two incompatible APIs needs to adapt to that. No more than this API change is what happened, and I fail to see how Google is to blame for it.

I'll put it in terms even you can understand... "If it ain't broke, don't fix it."

Thanks that you agreed to come down to my kindergarten spot but anyway. I call bullshit.

This is not about fixing things, because nothing was broken.
This is about software development and the natural progression in API/ABI scope. Ever wondered why Pat sometimes recompiles packages with a "Shared library .so-version bump" message? That is because ABI's change. It has nothing to do with nutballs or "If it ain't broke, don't fix it", but has everything to do with adding new functionality.

Hello everyone. I tried installing virtualbox-kernel using ponce's slackbuild and it failed.

Any idea how to fix it? Thanks.

Hi vaenby, we haven't touched the virtualbox-* scripts from what's in SBo.
BTW, this seems fixed in newer virtualbox versions: you can try pinging the SlackBuild's maintainer in the eventuality that maybe he got a new set of build scripts for you to test.

Hi ponce. I successfully build virtualbox-kernel by applying the patch in that link. Thanks.

Thanks a lot. I have been waiting with adapting my Slackbuild to 14.2 until it's out but you've already done it:)

I have to say this just because it builds like the maintainer wants. and it even get into the main stream. The problem is breakage and that leads us to what the others distro's do. Some way to keep this so when you up grade to your git it it doesn't ruin 2 years of development in slackware 14.1 when using slackware 14.1. That's what I have to say that program I use for work and on my helpers systems. And because a maintainer says oh I want it to build on my computer in 14.1 lets break 2 years of development because. we need to run everything in /usr/lib or usr/lib64.
This is my rant till we and I mean me as trying to help. from my point of viewe slackbuilds is pretty broken for slackware 14.1.
Now Ponce before you freak out. I understand there is no way you can test it all. but some things a blind man can see.
so when you click commit remember all my work on qt went to !@#$^& and 2 years down the drain and the loss of way to much time.
never ever depend on Slackbuilds again.

Mon Nov 4 17:08:47 UTC 2013
Slackware 14.1 x86_64 stable is released!
that is what we build against except for security patches.
Sat Oct 31 01:34:24 UTC 2015
audio/qjackctl: Updated for version 0.4.1.
requires qt5
you do not use slackware I guess to work on qt projects.
but I bet it worked on your maintainer computer right it built.
tell you what I run Eric plasma 5 and am working on so many problems with running the qt4 and the new frameworks. It's not like qt3 where it was pulled into the project. Nothing like that.
I guess I will ask Pat to change how ld.so.conf works in slackware. and have it point to per program.
lets work on 14.1 because 14.2 is going to have the same proble.
How about a read me from the maintainer that says this install in usr/lib and when a qt program your working on calls for a qtlib with ldconf.It may break slackware.

Drakeo, your point made zero sense to me.

As a maintainer of a small handful of SB's I will wait until the first RC and then test mine out from the github (current) version. Mine are mostly leaf-node (or close to) SB's.

I have no doubt that those involved in this tricky operation know exactly what they are doing. But I do wonder why we couldn't just fork the 14.1 SlackBuilds and continue adding and refining the 14.1 SlackBuilds. After all, many systems will run 14.1 for a while to come yet. Then perhaps a big notice on the submit page encouraging maintainers to test against the github fork (current -> 14.2) in preparation for the release.

It begs the question; should we allow the upload form to take SB's from the current release and the last release (leap frogging). This gives users of the previous Slackware version more time whilst fully supported before they move to next release. However, it means more work for the maintainers, if they choose to maintain the previous release with up-to-date SB's. Once the transitional period is entered, as it has done recently, the previous release (in this case 14.0) would freeze. The current release (in this case 14.1) would continue to accept uploads. And the next release, (in this case 14.2) would start accepting uploads to improve on, and/or fix the SB's that were forked from the current release (14.1) at the start of the transistional period. I do realize that referring to "current release" is confusing when we use "current" to mean "next release in development".

I've just realised that this release cadence is almost unique within Linux to Slackware. I can't think of any other distro that has stable releases, yet has a rolling repository atop. Perhaps one of the (many) OpenSUSE genomes has similar dynamics. FreeBSD ports stay rolling throughout the various releases. They do a remarkably good job of that too. In ports there is no focus on a base release version at all, it just rolls constantly. I wonder how they pull that of. The continual build testing by Poudriere server farms must help a lot. I suppose having dependency resolution helps also. Their libc ABI compatability is good, it never breaks within major versions. But that shouldn't be an issue for Slackware, since all SB's build on top of fixed release (ABI). And since the Slackware base is large, and since all SB's build from source, only the API compatability between the various SB's should be an issue. As must be the case with ports.

In any case; having packaged for Debian, Slackware and FreeBSD, Slackware is by far the easiest and most joy to package for. I think a big part of that is the relaxed approach, giving freedom and lack of restraints to the packager. Keeping it simple where it needs to be. The other big reason is that we only target two architectures (i486 and x86_64) and one release. Which contradicts my suggestion above. Just thinking out loud :-). I also think the way we submit, review and push new and updated SB's is really nice. My only complaint would be that the time taken for the approved queue to get synced to the production repo is a bit too long (infrequent). If they are approved, what's the hold up.

Hi, after getting the recent 'bluez/pulse'-upgrade installed I needed to recompile packages like inkscape (which went ok) but pypoppler-0.12.1 (needed for pdfshuffler) did not compile. It threw this error:

Does anyone have a suggestion how to solve this?

Cheers,

Rob

Yes Rob, pypoppler in SBo was broken by the recent upgrade of poppler to 0.40. Our usual crash test dummies (Arch and Fedora) haven't yet updated to poppler-0.40, so they have no patches for us to plagiarise. Upstream is pretty much dead. *However*, the good news is that upstream's bug tracker is still active, and this breakage is logged as bug 1528489.

https://bugs.launchpad.net/poppler-python/+bug/1528489

In which we see that Gentoo is on the case and has a patch.
https://launchpadlibrarian.net/23099...-changes.patch

The patch should let you get it built, and if that works for you I'll get it into SBo master in due course.

This has pretty much already happened, except that the big notice was on the mailing list, and the repo is on SBo's own server instead of github.

Submissions to 14.1 have been closed to keep the admin workload under control. It's quite possible that there will be selected backports and fixes in the 14.1 branch before 14.2 is released, and maybe a few more after that -- this is what happened in the 14.0 to 14.1 cycle. I remember SBo mgmt suggesting backports right up until we were put out of our misery ;)

It's not as if SBo's 14.1 will go away: users of the previous Slackware version will still have their own SBo branch for as long as they like, albeit frozen with package versions that are compatible with their Slackware installation.

Work for the maintainers is the main obstacle. There wouldn't be any choice; to do the job properly, maintainers would need to test in four clean build environments (or *eight* if the suggested "optional PAM" happened).

Everything approved goes into the approver's publicly available git branch immediately, but issues do come to light occasionally that get fixed after approval and before the approximately weekly update. If you follow the approver's branches, you can help to discover those issues :)

Yip, that works. Saving that file in the patches folder for pypoppler and then adding the line below the list of patches in Sbo's pypoppler.SlackBuild does the job.

Thanks fivefiveamsterdam!-)

Thanks, fixed in my branch for 14.2 already

Hi Willy, can I find your package somewhere?