Package Details: lib32-shaderc 2020.0-4

Git Clone URL: (read-only, click to copy)
Package Base: lib32-shaderc
Description: Collection of tools, libraries and tests for shader compilation (32bit)
Upstream URL:
Licenses: Apache
Conflicts: lib32-shaderc-git
Submitter: oxalin
Maintainer: oxalin
Last Packager: oxalin
Votes: 1
Popularity: 0.015608
First Submitted: 2019-08-15 16:26
Last Updated: 2020-05-05 14:32

Latest Comments

1 2 Next › Last »

oxalin commented on 2020-05-04 05:50

@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).

Samega7Cattac commented on 2020-05-03 13:48

I have the same issue as @Nocifer conflicts with shaderc

thaewrapt commented on 2020-05-03 12:45

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

Nocifer commented on 2020-05-03 08:58

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.

DDoSolitary commented on 2020-05-03 03:06

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

eschwartz commented on 2020-05-03 03:04

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.

DDoSolitary commented on 2020-05-03 03:00

I don't think it is caused by the missing double quotes because it is pretty uncommon to build packages in a path that needs to be quoted (though quotes should still be added for those uncommon scenarios).

The actual problem here is that $pkgdir contains an absolute path so there is no need to add ${_pkgbasename}-${pkgver}/ before it.

eschwartz commented on 2020-05-03 02:46

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

Pretty obvious issue here, I'd think. Deleting the quotes around the pkgdir variable was pretty astonishing, too.

I had no problem installing this package (just to be sure, I always use pacaur to install my own package once it has been submitted).

You claim that you used pacaur to install the published version, however, the published version cannot under any circumstances have deleted those files properly. And I cannot imagine how the CMakeLists.txt could fail to install them.

So you're either misremembering or lying that you double-checked with pacaur, or else (this is a wild guess, but pacaur does dumb things all the time, so maybe) pacaur did something stupid like reuse a cached .pkg.tar which you built with makepkg using a different PKGBUILD than the one you published, which would mean your check was a waste of time to begin with. Do you remember if pacaur actually showed build output? Do you use pacaur with the idiotic --silent flag (see above under "pacaur does dumb things")?

I do, however, have a small tip for you. Don't use the -f flag to rm. It's bad and does bad things. If your rm command is completely broken and does something totally wrong, trying to delete files that cannot possibly exist, then -f causes it to ignore errors. Ignoring errors is bad. Using rm -f in a PKGBUILD is like using make || true. It's possible you might have a good reason to do it, but that's rarely the case.

Using rm -r without -f would cause that to fail during package() instead of failing due to pacman file conflicts.

oxalin commented on 2020-05-03 01:41

@thaewrapt please, don't flag a package as being out-of-date because there is a comment about a bug. Moreover, the comment was sent earlier today, give some time to address the issue. Out-of-date flag is to be used when the source changes. Otherwise, add a comment or use "Submit a request"

About @Nocifer's comment, I had no problem installing this package (just to be sure, I always use pacaur to install my own package once it has been submitted). While the include, share and bin folders are supposed to be deleted when packaging, the installation folder changed in the last update to mirror the arch package and I may not have deleted the folders properly. I'll investigate the problem later or in the next few days (I have other things on the back burner for now).

Nocifer commented on 2020-05-02 08:29

Latest update causes this to break because of conflicting files with shaderc:

error: failed to commit transaction (conflicting files)
lib32-shaderc: /usr/bin/glslc exists in filesystem (owned by shaderc)
lib32-shaderc: /usr/include/shaderc/env.h exists in filesystem (owned by shaderc)
lib32-shaderc: /usr/include/shaderc/shaderc.h exists in filesystem (owned by shaderc)
lib32-shaderc: /usr/include/shaderc/shaderc.hpp exists in filesystem (owned by shaderc)
lib32-shaderc: /usr/include/shaderc/status.h exists in filesystem (owned by shaderc)
lib32-shaderc: /usr/include/shaderc/visibility.h exists in filesystem (owned by shaderc)
Errors occurred, no packages were upgraded.