Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

graphene: update to 1.10.0 #20289

Closed
wants to merge 2 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 1 addition & 1 deletion common/shlibs
Expand Up @@ -3624,7 +3624,7 @@ libFAudio.so.0 FAudio-19.05_1
libqaccessibilityclient-qt5.so.0 libqaccessibilityclient-0.4.0_1
libnitrokey.so.3 libnitrokey-3.4.1_1
libceres.so.1 ceres-solver-1.14.0_1
libgraphene-1.0.so.0 graphene-1.8.2_1
libgraphene-1.0.so.0 graphene-1.10.0_1
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we were supposed to make sobumps each time we update libraries, sorry if thats not the case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well if thats the case I was working on a mutter update that needs the new symbols provided (at least meson enforces such version), but I didn't know that back then.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Package version shouldn't need to be changed in common/shlibs unless the soname/symbols change.

libflite.so.1 flite-2.1_1
libflite_cmu_us_kal.so.1 flite-2.1_1
libflite_usenglish.so.1 flite-2.1_1
Expand Down
10 changes: 5 additions & 5 deletions srcpkgs/graphene/template
@@ -1,25 +1,25 @@
# Template file for 'graphene'
pkgname=graphene
version=1.8.2
revision=2
version=1.10.0
revision=1
build_style=meson
build_helper="gir"
configure_args="-Dtests=false -Dbenchmarks=false
-Dintrospection=$(vopt_if gir true false)"
-Dintrospection=$(vopt_if gir true false) -Darm_neon=false"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I remember correctly NEON is not architectural in armv6 and armv7, so apart of circumventing the error we can ensure compatibility with all armv* devices regardless of the extensions present on their CPUs.

Copy link
Contributor

@jnbr jnbr Mar 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neon was introduced with armv7 but support was optional. Void does not use neon for armv7 (with some exceptions). So for armv6 and armv7 this is ok, but it should not be disabled for armv8 / aarch64.

hostmakedepends="pkg-config"
makedepends="libglib-devel"
short_desc="Thin layer of types for graphic libraries"
maintainer="Enno Boland <gottox@voidlinux.org>"
license="MIT"
homepage="https://github.com/ebassi/graphene"
distfiles="${GNOME_SITE}/graphene/${version%.*}/graphene-${version}.tar.xz"
checksum=b3fcf20996e57b1f4df3941caac10f143bb29890a42f7a65407cd19271fc89f7
checksum=406d97f51dd4ca61e91f84666a00c3e976d3e667cd248b76d92fdb35ce876499

build_options="gir"
build_options_default="gir"

post_install() {
vlicense LICENSE
vlicense LICENSE.txt
}

graphene-devel_package() {
Expand Down
2 changes: 1 addition & 1 deletion srcpkgs/gst-plugins-base1/template
@@ -1,7 +1,7 @@
# Template file for 'gst-plugins-base1'
pkgname=gst-plugins-base1
version=1.16.2
revision=1
revision=2
wrksrc="${pkgname/1/}-${version}"
build_style=meson
build_helper="gir"
Expand Down