Well, the patch written by Larry for the SBo script of qt5 modifies the qtwebengine source (actually Chromium sourcecode) to match the changes in mozilla-nss. Whereas the patch I linked to is how it has been solved in Qt, by the Qt developers themselves:

Yes, it's a different patch
Probably we need to include it in SBo
I will test this patch soon

As Larry wrote the previous patch and is the maintainer on SBo for qt5 I would prefer if he reviews the new one before it gets committed.

I was finally able to build qt5, the SBo-git file was corrupt for some reason (I guess connection issues) and I didn't notice that.

Also poppler-qt5 still points the old version of poppler 0.42.0.

So, thanks for all the help!

I have pushed poppler-qt5 in my branch but not yet merged into master

for me its working.. yesterday installed sbopkg on a -current , no issues yet.

In academic: finchtv-1.3.1 is no longer downloadable from geospiza. A direct link that gets it from cyberspace is: http://freecode.com/urls/c89c7ebc458...462150e7d13469

the md5sum of that download is identical to the source I had on my computer (originally from geospiza) and as given in the current info-file:
Maybe best to put this in the the source-repository for slackbuilds and provide a link to that from the info-file as this program won't ever be upgraded for unix; the next version is only for mac/windows.

I'm afraid that's not possible: quoting from the README
if geospiza people require that, they have to provide the 1.3.1 tarball (and if they don't someone should complain directly to them): we cannot do like freecode (that seems not to care about it).

1 members found this post helpful.

You're right; they still ship it themselves; I noticed after going through the registration motions (see png). But the Sbo script does not work as one would expect because of that.. you get a download error. Maybe the Sbo-script should explicitly put that README message as the output-error after not finding the source????? That would still keep things simple; but you might reply that one is always supposed to check the Readme, even for programs one is very familiar with.. Anyway, with the need to register for it, should it not go into /opt???

Attached Thumbnails

 

The script doesn't download anything. The script doesn't even know there's been an error. If you're using sbopkg, it's sbopkg that gives you that error. Maybe Willy would consider a patch. Other tools may handle it already, eg. I've taught slackrepo about the five packages to which this situation applies (Xyce, amd-app-sdk, jdk, finchtv, J-Link) and you get a nice message telling you what to do.

That's not what /opt is for. Simply, /opt is for anything that can't easily be persuaded to use the conventional directories. Maybe it's the tendency for proprietary software to be 'special' that has misled you.

This thread is about SBo scripts, isn't it?

Would inserting something like this
just before un-tar-gz-ing the source not do the trick? One just have to make the slackbuild aware of this very possible error...

PS I basically nicked that bit from Simone Giustetti's iscan.Slackbuild

I think that is going away from what SlackBuilds are supposed to accomplish. They are designed to build a program from source that is locally on the machine. If that source isn't there, tar will complain and the SlackBuild will exit. I don't see any reason to complicate the scripts just because the way you get the source (which isn't accomplished with the script) is different from most. As 55020 mentioned, if a check were to be added, it would belong in sbopkg, not the SlackBuild itself.

Oh, I see, did I stumble on a sectarian issue; manualdownload-builders vs slackpackagers vs sbopkgers? All using the same scripts but somehow it's not the same in the end.... Anyway, I am not proposing this check for each SlackBuild for each package in all the versions of the repository; that would be silly; it's just that the combination of script and info-file (that both live in the same tar.gz) yield an error specific for this package (leaving out the ones 55020 mentioned), because of the way the source has to get retrieved, when combined with automatic downloading (is that specific for sbopkg only?? ).

What makes it wrong to adjust a slackbuild to make thinks work for a more general public as long as it does not affect the principle of building from source present on the machine? Why would a couple of extra lines that are not needed for home-downloaders be hurtful if it does not affect their method of compiling but could make it easier for someone else using a tool that automates this?? Is this not what maintainers can decide when they adjust build templates? I am just asking; I am all for pragmatics to make things work; principles are guides one might need to step away from when something different comes along..

I don't really see the point of doing that. One should be reading the README anyway even if they are using sbopkg or another script to automate the process. I'm not sure how sbopkg works, but in my own script that I use to manage SlackBuilds, I have an option to get the source from a local directory instead of downloading it from the url in the info file. That way, in cases like this you can still use it to build and install but skip the download without throwing an error. Maybe a similar option could be added to sbopkg if it doesn't already have it, but I agree that the SlackBuild is not the place to put such checks.

The thing that I think you aren't understanding is that the SlackBuilds are not meant for any portion of downloading the source, including checking if the source exists (although, that occurs as a byproduct of trying to extract the source, since it will fail if the source isn't there or isn't a proper archive). It is the job of something outside of the SlackBuild to ensure the download is there, either the automated builder (sbopkg, et al) or the person manually starting the download. With sbopkg, it shouldn't even attempt to run the SlackBuild, because the download won't be there, and it would've errorred out either during the download or during the MD5 check. The SlackBuild wouldn't even be accessed to run the little check you're proposing.

And if you are the one manually running it, it is on you to verify the download occurred and that the MD5 matches the .info file. In that case, it would still fail your checks before the SlackBuild is even run.

As others have mentioned, you should be reading the READMEs for each package before you attempt to build it. The package maintainers write those to ensure that the package builders (you) have all the information needed to properly compile the package.

To repeat, the realization that the download isn't correct should be found before the SlackBuild is even run, either by an automated script or by you.