Package Details: bcc-tools 0.5.0-1

Git Clone URL: (read-only)
Package Base: bcc
Description: BPF Compiler Collection - Tools
Upstream URL:
Keywords: control eBPF kernel performance tracing
Licenses: Apache
Conflicts: bcc-tools-git
Submitter: troyengel
Maintainer: edh (eklausmeier)
Last Packager: edh
Votes: 21
Popularity: 2.688905
First Submitted: 2016-01-01 18:37
Last Updated: 2018-02-15 23:03

Dependencies (12)

Required by (1)

  • bcc (optional)

Sources (2)

Latest Comments

edh commented on 2018-02-15 23:10

I recently adopted the package and will try to maintain it in the future as good as possible. The very recent commit first of all update the package to v0.5.0 and basically overhauls the entire PKGBUILD. In addition to slight cosmetic changes I altered the following:

  • Patch cmake configuration using a git-commit from master

  • Move man pages into the "correct" place (but not the binaries)

  • Adjust architecture field for arch-independent packages like python bindings and scripting tools

  • Cleanup build directory handling

  • Add dependencies required for checking the package to checkdepends (checking is done while building; there is no separate check task)

  • Remove outdated patch concerning cppex

Please let me know whether you have any addition request or recommendations!

cippaciong commented on 2018-02-15 15:47

I have used v0.4.0 and now I'm using v0.5.0 without particular problems on arch. There is an open issue at with PKGBUILDs for both versions.

P.S. thanks edh for stepping up maintaining this package

cramaker commented on 2018-02-15 15:40

Any chance we could get this updated to the v0.5.0 release?

troyengel commented on 2017-08-10 18:37

Heya all, I just lack time and effort to maintain these packages - I'm going to disown them so another can pick up next. Be careful pushing a new release, apparently there's a clang/llvm bug (according to upstream) that causes everything to segfault - if you have an older compiled version installed, don't upgrade until that's fixed. (

cc: bcc, bcc-git packages

lilydjwg commented on 2017-08-08 15:08

The manpages are in the wrong place: it's under /usr/share/bcc/man/ and man can't find them. They should be in /usr/share/man/.

troyengel commented on 2017-08-01 23:01

@edrex thanks for the heads up, I have subscribed to the Github issue. Let's see what happens - maybe a patch, maybe a new version release...

edrex commented on 2017-08-01 21:43

Runtime segfault with all tools, reported here:

Possibly an issue with LLVM 4.0.x.

edh commented on 2017-06-25 19:38

Yes, I would still leave python2-bcc as optional dependency.
All the arguments boil down to an incomplete implementation of the provides field in the AUR and since Arch by default uses python3, I would stick to that version as well. The problem does not exist in the official report and hence there is no official policy.

Either way the most important part is for the package to provide working binaries without additional required optional dependencies.

troyengel commented on 2017-06-21 23:21

*nod* so to be clear, we are then saying by necessity that the python2-bcc bindings will remain optional, correct? The default python for Arch is v3, python2 is not considered the "we expect everyone to have this installed" so if we hard require python2-bcc as well, it would trigger an unwanted python2 on the "standard" Arch where it was not already in place. Or at least I think that's how the maintainers position it (can't seem to find a definitive statement).

As a general user, I have so many things that require py2 that I just want to ensure that we do what's best and not accidentally suck down python2 if it's not considered standard regardless of my personal system. The wiki really doesn't say one way or another, advice welcome.

edh commented on 2017-06-21 15:30

The best solution in the official repos would be to use the provides field just like you proposed. However I guess most AUR helpers will not resolve this correctly. Hence since we are in the AUR and our possibilities are limited, I would settle for specifying python-bcc as hard-dependency.

I agreed that the project handles things pretty unconventional. Considering that the actual executable (python or python3) still resides under /usr/bin, it does not matter that much despite looking odd.
The only thing you can still do is either symlink every tool or add the directory which contains the executables to the PATH.

P.S. Sorry for the late response. To be honst, I simply forgot to sign up for notifications for this package.

All comments