[SOLVED] Requests for -current (20151216)

DarkVision · 05-03-2016, 11:37 AM

Quote:

Originally Posted by DarkVision

As said, have just tested the latest release 0.3.6 which depends on libswscale and not sure if it is worth including this driver if you have to install ffmpeg also. But from the latest commits it looks like this dependency has been removed, maybe i'll give git a try.

Just compiled latest git and there does not seem to be any dependency to ffmpeg anymore. Besides the documentation there is only one library file and one symbolic link to it included in the package.

Code:

gcc >= 5.3.0-x86_64-3
gcc-g++ >= 5.3.0-x86_64-3
glibc-solibs >= 2.23-x86_64-1
libICE >= 1.0.9-x86_64-1
libSM >= 1.2.2-x86_64-1
libX11 >= 1.6.3-x86_64-1
libXext >= 1.3.3-x86_64-1
libva >= 1.7.0-x86_64-1
mesa >= 11.2.1-x86_64-1

Thx to bassmadrigal for the clarification. The ArchWiki has similar information

Quote:

AMD Radeon HD 4000 series and newer GPUs are supported by the libvdpau-va-gl package together with the libva-xvba-driver package.

OK, the libva-xvba-driver is not yet included in -current so these GPUs might not be able to use VDPAU? Maybe then it is really not worth adding it just to make some intel users happy. No problem, sorry for the noise.

cwizardone · 05-03-2016, 11:59 AM

Quote:

Originally Posted by qunying

OpenSSL 1.0.2h security releases due 3rd May 2016

It has been released.

https://www.openssl.org/

bassmadrigal · 05-03-2016, 12:11 PM

Quote:

Originally Posted by DarkVision

OK, the libva-xvba-driver is not yet included in -current so these GPUs might not be able to use VDPAU? Maybe then it is really not worth adding it just to make some intel users happy. No problem, sorry for the noise.

Based on my previous research (although, this was DEC of 2014, so it might be a bit dated), the XvBA support was only provided with the binary radeon driver. Initially, it was in competition with VDPAU and VA-API, however, the libva-xvba-driver was created that allowed it to work with software that supported VA-API. Then, in conjunction with libvdpau_va_gl, it could be made to work with software supporting only VDPAU. However, at that point, you're transitioning between 3 systems, and the performance hit was substantial on VDPAU, so it was generally recommended to to try to stick with VA-API (since most software didn't support XvBA natively). Luckily, the semi-recent opensource drivers (for the past year and a half or so) supports VDPAU out of the box, as do the really recent AMDGPU (both the opensource and proprietary components), so no wrappers are needed.

Long story short (if I am understanding it all correctly)... libva-xvba-driver might only be needed when using the older, non-amdgpu, proprietary AMD driver. VDPAU is used on all other hardware other than Intel, which uses VA-API. Intel owners could use libvdpau_va_gl to add acceleration for Intel hardware with VDPAU-only software.

Nille_kungen · 05-03-2016, 02:00 PM

Quote:

Originally Posted by bassmadrigal

If I remember correctly, it is primarily Intel hardware, however, I believe the older versions of AMD's proprietary driver use it (I believe anything based on the newer amdgpu driver uses vdpau). Nvidia (proprietary and opensource) and Radeon (opensource radeon and opensource/proprietary amdgpu) use vdpau.

That's correct, it could be used by catalyst together with xvba-va-driver but catalyst is more or less dead and doesn't support current.
The overhead of the translations thru all layers will take away most of the winnings on catalyst so there never really were any real use for it on AMD hardware. and i think it's a horror story by it self if you look at what actually happens.
That leaves Intel as the only driver that use it.
I think SBo is the right place for it or maybe extra but i think SBo is better.

gmgf · 05-03-2016, 07:14 PM

new harfbuzz-1.27.7

https://www.freedesktop.org/software...-1.2.7.tar.bz2

gmgf · 05-04-2016, 01:21 PM

new hplip-3.16.5

http://hplipopensource.com/hplip-web/index.html

http://hplipopensource.com/hplip-web/release_notes.html

changes

just add new models support and qt5 support.

tested here, work.

gmgf · 05-04-2016, 02:55 PM

Robby, it seem the dbus package has include dir in /usr/lib64/dbus-1.0/include/dbus/dbus-arch-deps.h insted of /usr/include/dbus-1.0/dbus/

DarkVision · 05-04-2016, 03:08 PM

Quote:

Originally Posted by gmgf

Robby, it seem the dbus package has include dir in /usr/lib64/dbus-1.0/include/dbus/dbus-arch-deps.h insted of /usr/include/dbus-1.0/dbus/

The location in /usr/lib64 seem to be correct... have a look here and here.

reclusivewriter · 05-04-2016, 03:10 PM

Mutt just released a bug-fix version 1.6.1. No other changes in this version.

http://www.mutt.org/news.html

gmgf · 05-04-2016, 03:17 PM

i try to compil the new pyqt-5.6 and he is looking this dbus-arch-deps.h include in /usr/include/dbus-1.0/dbus/ not on /usr/lib64/dbus-1.0/include/dbus/

DarkVision · 05-04-2016, 03:29 PM

Quote:

Originally Posted by gmgf

i try to compil the new pyqt-5.6 and he is looking this dbus-arch-deps.h include in /usr/include/dbus-1.0/dbus/ not on /usr/lib64/dbus-1.0/include/dbus/

Looks like a bug in pyqt, ArchLinux seem to have a fix for that (not tested), have a look at the sed-command in the PKGBUILD here. Might be worth a try (you have to adjust the location of the configure.py script for the sed-command). Might be fixed in next release according to the bugreport.

gmgf · 05-04-2016, 03:50 PM

Ok, thanks, i have solved with a symlink

Sorry for the noise

DarkVision · 05-04-2016, 04:06 PM

Quote:

Originally Posted by gmgf

Ok, thanks, i have solved with a symlink

Sorry for the noise

no problem... for myself i would remove the symlink after next release of PyQT but if the symlink will work for you right now... everything is fine

USUARIONUEVO · 05-04-2016, 05:45 PM

linux-4.4.9 IS READY!!

https://cdn.kernel.org/pub/linux/ker...x-4.4.9.tar.xz

gmgf · 05-05-2016, 01:04 PM

new stunnel-5.32:

Version 5.32, 2016.05.03, urgency: HIGH
* Security bugfixes
- OpenSSL DLLs updated to version 1.0.2h.
https://www.openssl.org/news/secadv_20160503.txt
* New features
- New "socket = a:IPV6_V6ONLY=yes" option to only bind IPv6.
- Memory leak detection.
- Improved compatibility with the current OpenSSL 1.1.0-dev tree.
- Added/fixed Red Hat scripts (thx to Andrew Colin Kissa).
* Bugfixes
- Workaround for a WinCE sockets quirk (thx to Richard Kraemer).
- Fixed data alignment on 64-bit MSVC (thx to Yuris W. Auzins).

https://www.stunnel.org/downloads/stunnel-5.32.tar.gz