Package Details: libsepol 3.6-2

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
Submitter: Siosm
Maintainer: IooNag
Last Packager: IooNag
Votes: 112
Popularity: 0.23
First Submitted: 2013-11-03 20:05 (UTC)
Last Updated: 2024-02-24 08:45 (UTC)

Latest Comments

1 2 Next › Last »

eltongermano commented on 2023-12-16 00:34 (UTC)

To install updated PGP keys run: wget && gpg --import B8682847764DF60DF52D992CBC3905F235179CF1.asc

Louis commented on 2023-05-01 22:10 (UTC) (edited on 2023-05-01 22:10 (UTC) by Louis)

Jason's key can be imported running this command:

gpg --keyserver --recv-keys 63191CE94183098689CAB8DB7EF137EC935B0EAF

silverbluep commented on 2023-04-05 00:42 (UTC)

Petr Lautrbach's key expired or revoked; anyone building should import the other dev key.

IooNag commented on 2022-05-30 08:08 (UTC)

Pillgar: for information the gpg key is available on Ubuntu keyserver ( ) and on GitHub's user bachradsusi ( ). I also uploaded it on when I updated the SELinux packages, to make it easier to discover (and it seems you found the key on too). If you found a public keyserver which do not have this key, feel free to send an email to the SELinux mailing list ( asking for the key to be uploaded to this keyserver.

Pillgar commented on 2022-05-29 23:57 (UTC) (edited on 2022-05-30 04:57 (UTC) by Pillgar)

I'm getting an "ERROR: Remote key not fetched correctly from keyserver", when trying to upgrade this package. Not sure if the server is temporarily down, but I thought I'd mention it none the less.

Looks like that key was updated two days ago:

Update: gpg --keyserver --recv-keys BE22091E3EF62275 worked! I had incorrectly used pacman-key --recv-keys BE22091E3EF62275 before!

IooNag commented on 2020-05-18 20:34 (UTC)

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 (UTC)

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 (UTC)

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 (UTC) (edited on 2020-05-14 18:10 (UTC) by foxxx0)


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 (UTC)

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