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

ponce · 11-14-2022, 05:13 PM

Quote:

Originally Posted by gian_d

Hi, another issue is caused by the update of ffmpeg to 5.x version in Blender. The slackbuild for Blender 3.0.1 fails with the support to ffmpeg due the drastic changes in this version. The support to ffmpeg 5 was added in Blender since the version 3.1.0, but this version is not still compatible with Slackware current because it requires Python 3.10.
Then I extrapolated the changes in the source Blender 3.1.0 (ref https://github.com/blender/blender/c...d2d3f81057717a ) to make a patch which adapted them to Blender 3.0.1 sources.
The first version of the patch threw a new error but I was able to fix it just changing the name of a variable declared in a source file versus the original code.

Warning: the build ends successfully and after updating the package Blender starts regularly, but I cannot test the support to ffmpeg 5 in runtime because that's a feature of Blender that I don't use and I have no knowledge on this context. If someone can test in runtime the ffmpeg support of the patched package can help by reporting any runtime errors or confirming the full functionality.

The patch is quite long, just over 1000 lines of code, so I uploaded it in my repository on GitHub. It is available here: https://github.com/giandex/misc/blob...-ffmpeg5.patch

Regards

Hi Giancarlo, could you please ping the mantainer about this? It could be that he uses current too or have the possibility to ack this in any case...

gian_d · 11-14-2022, 05:40 PM

Done :-)

chris.willing · 11-15-2022, 03:07 AM

Quote:

Originally Posted by gian_d

The patch is quite long, just over 1000 lines of code, so I uploaded it in my repository on GitHub. It is available here: https://github.com/giandex/misc/blob...-ffmpeg5.patch

Thanks @gian_d - that was a mighty effort which seems to work OK here.

I've pushed a change to SBo which applies @gian_d's patch on condition that ffmpeg-5.1 is found, which ensures the SlackBuild is usable on both -stable and -current.

Similarly, for openimageio (required for Blender) I've pushed a change (similar to @gian_d's suggestion elsewhere) to conditionally use ffmpeg 5.1 if found at build time.

To summarize, after next SBo global update, both openimageio & Blender SlackBuilds at SBo will be usable without any change on both -stable & -current.

BTW, my limited test to check the Blender ffmpeg patch was to play a video in the Blender UI. Open File->New->Video Editing; select a video from file chooser on left and drag it to the timeline; then press play button.

chris

ponce · 11-15-2022, 03:55 AM

Quote:

Originally Posted by chris.willing

Thanks @gian_d - that was a mighty effort which seems to work OK here.

I've pushed a change to SBo which applies @gian_d's patch on condition that ffmpeg-5.1 is found, which ensures the SlackBuild is usable on both -stable and -current.

Similarly, for openimageio (required for Blender) I've pushed a change (similar to @gian_d's suggestion elsewhere) to conditionally use ffmpeg 5.1 if found at build time.

To summarize, after next SBo global update, both openimageio & Blender SlackBuilds at SBo will be usable without any change on both -stable & -current.

BTW, my limited test to check the Blender ffmpeg patch was to play a video in the Blender UI. Open File->New->Video Editing; select a video from file chooser on left and drag it to the timeline; then press play button.

chris

thanks Chris!

gian_d · 11-15-2022, 01:53 PM

Quote:

Originally Posted by chris.willing

BTW, my limited test to check the Blender ffmpeg patch was to play a video in the Blender UI. Open File->New->Video Editing; select a video from file chooser on left and drag it to the timeline; then press play button.

chris

That's a good sign! thanks Chris

andrew.46 · 11-18-2022, 11:17 PM

I see the smallest error in the ponce SlackBuild for gpac:

https://github.com/Ponce/slackbuilds...pac.SlackBuild

You will see:

Code:

chown -R root.root .

whereas the following is expected:

Code:

chown -R root:root .

Actually on closer examination I see this same error in the 15.0 SBo script...

ponce · 11-19-2022, 12:35 AM

Quote:

Originally Posted by andrew.46

I see the smallest error in the ponce SlackBuild for gpac:

https://github.com/Ponce/slackbuilds...pac.SlackBuild

You will see:

Code:

chown -R root.root .

whereas the following is expected:

Code:

chown -R root:root .

Actually on closer examination I see this same error in the 15.0 SBo script...

it's an old syntax still accepted by gnu chown that I unfortunately started using decades ago: with the new one in coreutils a warning (still not an error) is issued

Code:

2022-02-25  Paul Eggert  <eggert@cs.ucla.edu>

        chown: warn about USER.GROUP
        Suggested by Dan Jacobson (Bug#44770).
        * src/chown.c, src/chroot.c (main):
        Issue warnings if obsolete USER.GROUP notation is present.

let me say that I'm not the only old fart with bad habits: try this command in a SBo sources tree

Code:

grep 'root\.root' */*/*.SlackBuild

Didier Spaier · 11-19-2022, 02:57 AM

As an aside, out of laziness I often use a syntax like:
chown root: <file>.

I just realized that this is allowed by "man chown" which documents the GNU version of chown:

Quote:

If a colon but no group name follows the user name, that user is made the owner of the files and the group of the files is changed to that user's login group.

but not by POSIX:

Quote:

If the group portion of the first operand is given, the group ID indicated by it shall be used as the group argument; otherwise, the group ownership shall not be changed.

So from now on I will write:
chown root:root <file>
or:
chown 0:0 <file>
as numeric user and group ID are allowed.
In many cases the GNU utilities provide options not specified by POSIX (which I try to avoid) but here the behavior diverges from the specification...

andrew.46 · 11-19-2022, 09:45 PM

Quote:

Originally Posted by ponce

it's an old syntax still accepted by gnu chown that I unfortunately started using decades ago: with the new one in coreutils a warning (still not an error) is issued

I did not know that, thanks

.

3rensho · 11-28-2022, 11:02 PM

Clamav-1.0.0

Looks like a major change to the code and the SlackBuild no longer works.

Code:

.
.
.
clamav-1.0.0/clambc/bcrun.c
clamav-1.0.0/clambc/CMakeLists.txt
clamav-1.0.0/.gitattributes
tar: /mnt/storage/patches/clamav/clamav-1.0.0-vendor.tar.xz: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now

The "vendor*" bits now seen to be in the source tree and it is using rust as well.

Code:

.
.
.
-rw-r--r-- jenkins/jenkins   64004 2022-11-23 19:55 clamav-1.0.0/libclamav_rust/.cargo/vendor/serde/src/ser/mod.rs
-rw-r--r-- jenkins/jenkins    5273 2022-11-23 19:55 clamav-1.0.0/libclamav_rust/.cargo/vendor/serde/src/ser/impossible.rs
.
.

kgha · 11-29-2022, 12:57 AM

Quote:

Originally Posted by 3rensho

Clamav-1.0.0

Looks like a major change to the code and the SlackBuild no longer works.

Your post first surprised me since I had just built version 1.0.0 successfully. I then realised that I had used an older buildscript from Ponce, without lines 120-127.

It might well be that my build misses out some functions due to the old buildscript. If I understand it correctly, the vendor stuff has to do with using databases/signatures other than clamav's own. All I know is that basic functions (upgrading the clamav database, checking files/folders) work as intended.

3rensho · 11-29-2022, 01:50 AM

Quote:

Originally Posted by kgha

Your post first surprised me since I had just built version 1.0.0 successfully. I then realised that I had used an older buildscript from Ponce, without lines 120-127.

It might well be that my build misses out some functions due to the old buildscript. If I understand it correctly, the vendor stuff has to do with using databases/signatures other than clamav's own. All I know is that basic functions (upgrading the clamav database, checking files/folders) work as intended.

Thanks for noting that. I'll give it a go.

3rensho · 11-29-2022, 02:04 AM

Well, in my case the lines 120-127 were not pertinent and I just commented out the line where the clamav-1.0.0-vendor.tar.xz was to be untared. Then it built fine. Thanks for letting me know it can be built.

kgha · 11-29-2022, 04:46 AM

As already mentioned, it might be that some functions are lost when built without the vendor stuff. However, I compared my package with the .deb and .rpm packages available from clamav.net and couldn't see any obvious differences. Same files. The /sbin/clamonacc file is smaller in the slackware package, but that could be because slackware is systemd-free.

ponce · 11-29-2022, 12:33 PM

I'll try to explain: with clamav-0.105.1 the developers introduced rust code in libclamav (libclamav_rust) that, like most of the other rust stuff, needed to download additional sources from the internet at build time: to avoid that (the SBo policy is that SlackBuilds shouldn't download anything at build time) I introduced the *-vendor-* tarball with said sources (generated with "cargo vendor" in the main clamav-0.105.1 sources directory) and forced the build system to look in the "vendor" directory (with the additional dedicated snippet in the SlackBuild).
with the new 1.0.0 version looks like the developers came to sense and included the additional rust sources themselves (in libclamav_rust/.cargo/vendor) telling the build system to use those so the snippet and the *-vendor-* tarball aren't needed anymore (I'll remove them whenever I'll push clamav-1.0.0 on SBo).

thanks for the heads-up but, that said, please, don't use this topic to report updates that apply also to stable... open a new one, thanks!