This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Esxi running macos For selur
I don't think dylib files should use 755 but 644, but okay.
No going to test this since I don't have the time or access to the vm.
May be someone else will test it.

Quote:I notice that if change permissions in files, i need to re-import them to Packages project manually. Otherwise Packages will read files with old permissions.
Those are probably infos that are included in the project data, so not that surprising. They will probably be set when adding the files and not checked afterwards.

Cu Selur
Reply
dylib 755 used in 100% of system files and app contents. vaporsynth dylibs use 755. Qt use dylib 755. So based on all that statistics i guess it is just safer to use 755 for dylibs.
Reply
In my opinion 644 is the right choice instead of 755 since at least I'm not comfortable with stuff I didn't code and compile myself to be executable if they no not need to be.

If you believe or are sure that none of the dylibs might contain harmful code and even if they should not be designed to be executed are okay to be executed that is fine with me.

The installer is your thing, do whatever floats your boat and with what you are comfortable with. (But it's not 'safer' to use 755 it's more dangerous.)

Cu Selur
Reply
Seems a lot of new bugs in Hybrid_wip_2020_09_21_2
Reply
like always: no details -> nothing to do for me Smile
Reply
Ok, but i can report only bugs that related to global components and so may be useful for 2020.09.15.1

In Hybrid_wip_2020_09_21_2 Base -> Processing -> Audio selection menu list became empty after i restart Hybrid few times.
When i copy all binaries (except Hybrid executables) and lib folder from 2020.09.21.2 to 2020.09.15.1 app contents, i still can reproduce same problem when launch 2020.09.15.1 few times. So seems it may be a bug in some updated lame, sox, faac, flac components but not in Hybrid executable itself.

[Image: lddieFt.jpg]
Reply
Okay, so the new sox wasn't detected which is why audio handling was disabled. Smile
Added fdkaac and uploaded a new version which should also ignore that the new sox doesn't report any version info.

Cu Selur
Reply
Yep, seems no problem in new version now.
Another interesting bug. If i select FAAC checkbox and render video, i got white noise instead of sound. Problem exists in both 2020_09_15 and 2020_09_22 versions, so i guess sit could be some bug in faac component itself.
I used that checkbox only for test now and never used it earlier.
[Image: 2lhuocn.jpg]
Reply
Found the problem: faac on mac uses other command line options nowadays.

Cu Selur
Reply
(20.09.2020, 18:16)l33tmeatwad Wrote: One thing I would recommend trying, I've added a shortcut from the /usr/local/lib/vapoursynth path to the framework one, I'd recommend installing to that path as it should install for both users that installed via brew or compiled themselves and vs installer.  I would double check, but the link should force it to forward the files to the framework the vs installer sets up (only for vs r52 or newer)
Still can't get it where to install but that shortcut looks like this:
[Image: 4e9kVVj.jpg]
Reply


Forum Jump:


Users browsing this thread: 4 Guest(s)