Arch Linux User Repository

I have the same issue as @Nocifer. Beeing not a AUR packaging guru, how do i update to "2020.3" ?

Yes, this was obviously an upstream bug, and then like DDoSolitary says I too noticed that this package is on 2020.0 and not the latest 2020.3, so updating to that fixed the issue. So, @oxalin, please update this package :)

Got the same error as @Nocifer. It seems that updating to 2020.3 fixes this.

I'm trying to build this package due to the lib32-gst-plugins-bad update today and I'm getting the following error:

[16/29] Building CXX object libshaderc_util/CMakeFiles/shaderc_util.dir/src/resources.cc.o
FAILED: libshaderc_util/CMakeFiles/shaderc_util.dir/src/resources.cc.o 
/usr/lib/ccache/bin/g++  -m32 -DENABLE_HLSL -I/tmp/makepkg/lib32-shaderc/src/shaderc-2020.0/libshaderc_util/include -D_FORTIFY_SOURCE=2 -march=native -O2 -pipe -fno-plt -D_FORTIFY_SOURCE=2 -I/usr/include/glslang -Wimplicit-fallthrough -O3 -DNDEBUG -Wextra-semi -Wall -Werror -fvisibility=hidden -fPIC -std=c++11 -std=gnu++11 -MD -MT libshaderc_util/CMakeFiles/shaderc_util.dir/src/resources.cc.o -MF libshaderc_util/CMakeFiles/shaderc_util.dir/src/resources.cc.o.d -o libshaderc_util/CMakeFiles/shaderc_util.dir/src/resources.cc.o -c /tmp/makepkg/lib32-shaderc/src/shaderc-2020.0/libshaderc_util/src/resources.cc
/tmp/makepkg/lib32-shaderc/src/shaderc-2020.0/libshaderc_util/src/resources.cc:142:6: error: cannot convert ‘<brace-enclosed initializer list>’ to ‘int’ in initialization
  142 |     }};
      |      ^
[22/29] Building CXX object glslc/CMakeFiles/glslc.dir/src/resource_parse.cc.o
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().
    Aborting...

Could some kind and more knowledgable soul share their wisdom with me? Could this be an issue with my custom CXXFLAGS in makepkg.conf (basically -march=native)?

@eschwartz: take a deep breath, no need to call me a liar. I honestly do this (creating and maintaining packages, and sometimes having to interact with other package maintainers) to the best of my knowledges and of my free time. I think we are all working in the same direction, so cool off. Sometime, I miss something and I fix it as fast as I can do. I updated the package hastily in between to activities with my child and, after updating and seeing no error, I thought everything had went just fine.

You were right though, something went wrong while updating the package and was not displayed properly. I use Octopi with pacaur and something in-between may not have followed. When I rebooted a bit earlier, I saw that the package was still at 2019.0. So I reverted the change to "${pkgdir}": As @DDoSolitary pointed out, this variable is an abolute path. And as you stated, removing the quotes shouldn't have happened (which was done inadvertently when modifying the path).

While your suggestion of removing the "f" parameter is right, I have not applied it for now. I'll include it in the next update. I'll have to remove the "share" from the folder list at the same time otherwise the rm command will fail (there is no "share" folder).

To everyone: let me know you encounter anything with the updated version (I double-checked that the package was really installed this time).

I have the same issue as @Nocifer conflicts with shaderc

@oxalin Sorry, my bad, thought the upstream (64-bit) version update caused the issue.

People, please, we're not competing here, we're trying to make this work. In any case, as @DDoSolitary and @eschwartz have already pointed out, this line in the PKGBUILD

rm -rf ${_pkgbasename}-${pkgver}/${pkgdir}/usr/{include,share,bin}

should become

rm -r ${pkgdir}/usr/{include,bin}

because $pkgdir is an absolute path that already points to pkg/$pkgname, so there's no need for that ${_pkgbasename}-${pkgver}.

Further, there is no $pkgdir/usr/share folder to be deleted, something that would have been noticed earlier if it wasn't for that -f flag which, as @eschwartz already pointed out, should not really be used with rm because it can hide errors such as this. A better way would be to remove share from {include,share,bin} and then simply get rid of the -f flag.

Also, yeah, it wouldn't hurt to keep shell variables wrapped in quotes to guard against the corner case of having spaces in the path name.

Oops I missed that "too" in your comment. Sorry.

Uhm. I said removing the quotes is also astonishing, not "the removed quotes are the reason why the error happened".

I don't often see people remove quotes from packages that previously had them, and independent of the critical issue here, that removal is in fact astonishing.