Package Details: bcc 0.3.0-1

Git Clone URL: https://aur.archlinux.org/bcc.git (read-only)
Package Base: bcc
Description: BPF Compiler Collection - C library and examples
Upstream URL: https://github.com/iovisor/bcc
Licenses: Apache
Conflicts: bcc-git
Provides: bcc, libbcc
Submitter: troyengel
Maintainer: j3thr0
Last Packager: troyengel
Votes: 18
Popularity: 0.223901
First Submitted: 2016-01-01 18:37
Last Updated: 2017-03-14 00:02

Latest Comments

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. (https://github.com/iovisor/bcc/issues/1221)

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:
https://github.com/iovisor/bcc/issues/1221#issuecomment-319498218

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.

https://wiki.archlinux.org/index.php/Python
https://wiki.archlinux.org/index.php/Python_package_guidelines

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.

troyengel commented on 2017-06-14 23:37

I happen to work with some folks who are paid to be packagers (not for Arch :)) and are Arch users themselves - after some chitchat, we agree that it makes more sense for python-bcc bindings to be a hard dependency.

The issue then to sort - the split package only has one bcc-tools, but you can optionally use py2 or py3 (or both) bindings. The only way I can see this working if we make a requires=python-bcc-bindings (?), then in both split packages add a provides=python-bcc-bindings ? (or maybe a variation of that) We can't just directly require one package or the other... ideas welcome.

@edh - we could add a profile shim, I'm not entirely sure that's right logistically though. What I mean is the /usr/share directory is supposed to be data files, and not a location that would normally be executable in the PATH, it's this project putting the files there as opposed to *bin/ directories (or like /usr/bin/bcc/*) making it a bit weird.. (ref: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA)

Side note, it was pointed out that we can't use makedepends() in the child split package areas (it's just ignored) so those need to get removed next build.

edh commented on 2017-06-08 19:57

Since we are already talking about changing the package :D
Would you mind adding a file which extends the PATH to include /usr/share/bcc/tools.

edh commented on 2017-06-08 19:45

I personally would classify python-bcc as a hard dependency of bcc-tools. Simply because I would expect a *-tools package to provide utility programs not libraries.
However I do not object having an additional lib package which contains merely libbcc.so being a dependency of bcc-tools. Though I would first check whether this new flexibility would be of any use for a current package in the AUR.

All comments