Package Details: libsepol 3.2-1

Git Clone URL: (read-only, click to copy)
Package Base: libsepol
Description: SELinux binary policy manipulation library
Upstream URL:
Keywords: selinux
Licenses: LGPL2.1
Groups: selinux
Conflicts: selinux-usr-libsepol
Provides: selinux-usr-libsepol=3.2-1
Submitter: Siosm
Maintainer: IooNag
Last Packager: IooNag
Votes: 103
Popularity: 0.41
First Submitted: 2013-11-03 20:05
Last Updated: 2021-07-03 14:38

Latest Comments

1 2 Next › Last »

IooNag commented on 2020-05-18 20:34

As a workaround of the build issue with gcc 10, it is possible to use clang. Using "make CC=clang" in build() seems to work fine (at least with the latest package, clang 10.0.0-2). I will test other SELinux packages and updates the PKGBUILD to use clang instead of gcc if it is confirmed to work.

IooNag commented on 2020-05-14 18:55

hashworks: Thanks for the build log. I managed to reproduce the issue after upgrading my system. It seems to be caused by gcc 10: on another Arch Linux system with gcc 9, libsepol still builds fine. This is therefore a serious issue and unfortunately I will not have much time to investigate it in the following days.

Nevertheless it seems that the current upstream master branch ( builds fine with gcc 10, but this could be caused by some changes in the way libsepol is linked (to help with LTO) that happened a few months ago, and these changes are not easy to backport.

If you have time to help make libsepol package compatible with gcc 10, please submit a Pull Request on

hashworks commented on 2020-05-14 18:18

I mainly used extra-x86_64-build here since we have a user where it doesn't build, but it worked for me with yay and makepkg. I could reproduce the error with extra-x86_64-build though. Here is the build log if you want to take a look:

foxxx0 commented on 2020-05-14 18:10


using devtools (e.g. extra-x86_64-build) only requires root privileges for setting up the chroot but for the actual build process a so-called "builduser" with the same uid as your current user is used.

nspawn only comes into play in the very last step where the package is installed into the nspawn'ed chroot in order to let makechrootpkg check if it installs without issues including hooks and what not

So just to be clear: using devtools for packaging Arch Linux packages is best practice and only that way you will get proper packaging support/help. If you want to have any chance getting any aur package imported to the repository (if it qualifies), it needs to be compatible with the devtools build process.

IooNag commented on 2020-05-14 17:59

hashworks: I do not use extra-x86_64-build because I prefer not to build packages as root and extra-x86_64-build uses systemd-nspawn which is incompatible with fakeroot+fakechroot, proot, docker, podman, etc. (I recently began using podman to build packages in clean environments). If you want to report an issue more precisely, please open an issue on

Thanks for the notice about the URL. I will update it with the next release (which would happen in a few weeks).

hashworks commented on 2020-05-14 17:42

Build fails with extra-x86_64-build, any idea?

Also, you need to update the upstream URL.

IooNag commented on 2017-02-04 08:58

lukeshu: the patches are post-release bugfixes which come from the upstream repository,

lukeshu commented on 2017-02-03 17:55

Who curated the list of patches?

IooNag commented on 2014-09-16 06:12

Done in New source URL is${pkgname}-${pkgver}.tar.gz
I'm waiting for the maintainer to update AUR packages from GitHub.


Anonymous comment on 2014-09-15 18:41

source url doesnt' exist.
Correct url:

Please change it in PKGBUILD