Package Details: vsxu-git 0.6.3.r0.g5404800f-1

Git Clone URL: https://aur.archlinux.org/vsxu-git.git (read-only, click to copy)
Package Base: vsxu-git
Description: A free to use program that lets you create and perform real-time audio visual presets.
Upstream URL: http://www.vsxu.com/
Licenses: GPL, custom
Conflicts: vsxu
Provides: vsxu
Submitter: speps
Maintainer: WoefulDerelict
Last Packager: WoefulDerelict
Votes: 5
Popularity: 0.000000
First Submitted: 2011-07-27 23:09 (UTC)
Last Updated: 2019-01-21 23:24 (UTC)

Latest Comments

1 2 Next › Last »

kleintux commented on 2023-08-29 15:35 (UTC)

the dependency https://github.com/vovoid/cal3d is down :)

WoefulDerelict commented on 2016-08-30 17:29 (UTC) (edited on 2016-08-30 17:38 (UTC) by WoefulDerelict)

pha-qu: Not at all. I figured I'd push the cleanest PKGBUILD for everyone instead of continuing to test the dirty one in the gist. I don't build/run vsxu enough to notice things like this. If it weren't for you I'd have probably missed it for quite some time longer. I'd only gotten around to some basic cleaning and updating since importing this and vsxu from AUR3. Unless any other issues arise I can finally check these packages off my list of things to properly update after a few more checks in /clean/ environments to detect any missing dependencies and hopefully spot any other boo boos. I'm glad I've gotten it cleaned up enough to work well for you and not puke out errors. Getting to poke at the build and dropping libpng12 is a definite bonus. I'm not sure why it was originally built that way but it is cleaned up now.

pha-qu commented on 2016-08-30 09:24 (UTC) (edited on 2016-08-30 09:27 (UTC) by pha-qu)

WoefulDerelict: I'll give that a spin later when I get back from work. Getting rid of that tired old dependency would be a real bonus, and one less thing for the package maintainer (you) to worry about. Win, win, what is there not to like :) <edit>Ignore me, I just noticed that change has already been pushed. Excellent stuff.</edit>

WoefulDerelict commented on 2016-08-29 20:17 (UTC) (edited on 2016-08-29 20:52 (UTC) by WoefulDerelict)

pha-qu: That is awesome. I have another fun thing you may want to try. It looks like I may have convinced cmake to play nice and build with with the newer version of libpng. If I can get both vsxu packages to do it I will probably abandon libpng12 for libpng. I'd love to know if it works for you. https://gist.github.com/WoefulDerelict/4408cd7337b9a6c144044aebccca5d17 EDIT: After testing in clean environments it looks like cmake will prefer libpng over libpng12 if one just leaves it to its own devices. Once I've had more time to test and make sure it works I think I'll push out updates that move to the newer libpng.

pha-qu commented on 2016-08-29 20:13 (UTC)

@WoefulDerelict Thanks very much indeed, I can confirm that the fix to libpng12 is successful all text is rendered correctly, and there are no errors spewing out of the console. thanks once again for an excellent job

WoefulDerelict commented on 2016-08-29 18:59 (UTC)

pha-qu: I generally tend to be near equipment that notifies me of new messages and a terminal to investigate them during the weekdays. Thanks for taking the time to do the leg work and describe the problem effectively so I could easily get up to speed and verify it. Hopefully I've created a workable solution that can perhaps be improved in the future. Also reminded me I needed to remove the .install scripts from the vsxu packages as the commands inside have been made redundant by the new pacman hooks. Enjoy your meal. I look forward to hearing how things go once you've had a chance to build and poke at things.

pha-qu commented on 2016-08-29 18:32 (UTC)

@WoefulDerelict Thanks for your prompt response, I'll have a look at the proposed repair a bit later. Food is calling my stomach ;) I'll post on the outcome once tested.

WoefulDerelict commented on 2016-08-29 17:11 (UTC) (edited on 2016-08-29 18:42 (UTC) by WoefulDerelict)

pha-qu: You raise some very interesting questions. It would be nice if we could smack the build upside its head and get it to focus on libpng instead of libpng12. I suppose this would be best to bring up with the vovid team as they would know the build system. I'm not sure what they are doing upstream for 0.6.0 as I have trouble getting that to build but there have been many changes to the rendering engine and the static inclusion of things like cal3d and freetype2 so I suspect the core issue of libpng12 may also be resolved in the future. I am not sure why the libpng12 package would lack the include files unless they were conflicting with libpng. They are quite obviously removed during the packaging process in the libpng12 PKGBUILD. It makes very little sense as lib32-libpng12 contains the default parent dependency for those headers which, as you've kindly pointed out, aren't there. This may be an issue to bring up with the package maintainer as it obviously makes for amusing problems not having them present. The build is only able to find headers for libpng16 and builds against them but will link against libpng12 if present as requested and silly things happen. I have a suspicion libpng12 really should include: /usr/include/libpng12, png.h, pngconf.h and that this is just a packaging mistake. I'm going to make a test PKGBUILD for libpng12 with the headers and see what happens when they are installed and vsxu is built against them as I suspect that should be fixed no matter what. I'm also going to see if vsxu will behave and build nice if we ask it to use libpng16. EDIT: cmake resists when I ask nicely that it use libpng16, finding and opting to use libpng-1.2.56+apng instead. I've created a modified recipe for libpng12 that includes the bloody header files along with a few other bits, cherry picking out only the files that conflicted with libpng. This was mostly limited to some symbolic links and man pages. Hopefully this will be helpful for applications still using libpng12. Please feel free to look at it and test it against vsxu yourself. The gist is here: https://gist.github.com/WoefulDerelict/23ca3183aa9ec0b240589c8cd9439f5c I've filed a bug against libpng12 and try to get the change included as I suspect this isn't the first or only time this will bite someone: https://bugs.archlinux.org/task/50574

pha-qu commented on 2016-08-29 16:43 (UTC)

libpng confusion, on application startup we have: libpng warning: Application was compiled with png.h from libpng-1.6.24 libpng warning: Application is running with png.c from libpng-1.2.56+apng The app runs fine, but cannot render any text? Checking with readelf The only mention of libpng: readelf -d /usr/lib64/libvsxu_engine_graphics.so 0x0000000000000001 (NEEDED) Shared library: [libpng12.so.0] Checking the cmake file on git: libpng12-0 (>= 1.2.46-3) Which seems to indicate that cmake uses a version greater than or equal to 1.2.46-3. Checking the pkgbuild: -DPNG_LIBRARY=/usr/lib/libpng12.so - that's good -DPNG_PNG_INCLUDE_DIR=/usr/include/libpng12 - directory isn't created by png12? Needs correcting? files created by libpng12 1.2.56-4 usr/lib/libpng.so.3 usr/lib/libpng.so.3.56.0 usr/lib/libpng12.so usr/lib/libpng12.so.0 usr/lib/libpng12.so.0.56.0 usr/share/licenses/libpng12/LICENSE The directory /usr/include/libpng12 is not created and libpng12 is no longer in AUR so there doesn't seem to be another png12 to be confused with. Why is cmake using png16 to build, and then ldd links with png12 - mad?! I thought I was going that way. Proposed solution: global virus to erradicate all windows boxes and their luddite ways, punishment for refusing to update system critical libraries. or Alternatively how do I persuade cmake and gcc/g++ to use the correct version of libpng and ldd to respect that choice?

WoefulDerelict commented on 2016-06-03 20:34 (UTC)

The issue involving the cal3d submodule failing to build against GCC 6.1.1 has been patched. If you encounter issues with fullscreen not being able to auto-detect and set the proper resolution you can pass the desired resolution via -s like in the following example: vsxu-player -s 1920x1080 -f

1 2 Next › Last »