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: None
Last Packager: troyengel
Votes: 18
Popularity: 1.446043
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.

troyengel commented on 2017-06-02 16:52

@eklausmeier sorry for the delay, been busy. Mentally I agree, technically it's possible though to use libbcc.so by writing your own python (or whatever). It's one of those areas that I see done differently in Arch than other distros, it's allowable to ship *some* binaries in a package that don't actually work unless you install the optional dependency, as they are not the *core* binary itself. While I think this is a bit odd compared to other methods (apt/dpkg, yum/rpm) it's how Arch works as a design.

All that said, I have no problems myself changing it to required it that's what we think collectively is the right thing to be doing, design patterns or not. Anyone else who happens to see this have thoughts?

eklausmeier commented on 2017-05-29 18:07

I think python-bcc is not an optional but rather a required dependency.

Without python-bcc, for example, execsnoop does not work.

troyengel commented on 2017-03-14 00:20

0.3.0-1 Release Note: 0.3.0 upstream added C++ examples, but their makefiles compile each one with a static copy of libbcc resulting in a huge compile time and space waste (+282megs). I've included a small patch to distribute the raw example *.cc files instead, and submitted an issue upstream: https://github.com/iovisor/bcc/issues/1048

troyengel commented on 2016-10-18 23:57

I'm about to release a new 0.2.0 package, be aware it does not provide Lua support yet. It appears we need a luajit static library that our luajit package doesn't create, I tagged an upstream issue for help sorting it out: https://github.com/iovisor/bcc/issues/566

troyengel commented on 2016-07-30 17:52

Something is going wrong in your build - the python-bcc package should have zero files in /usr/lib/python2.x -- it should look like this:

$ pacman -Ql python-bcc
python-bcc /usr/
python-bcc /usr/lib/
python-bcc /usr/lib/python3.5/
python-bcc /usr/lib/python3.5/site-packages/
python-bcc /usr/lib/python3.5/site-packages/bcc-0.1.8-py3.5.egg-info
python-bcc /usr/lib/python3.5/site-packages/bcc/
python-bcc /usr/lib/python3.5/site-packages/bcc/__init__.py
python-bcc /usr/lib/python3.5/site-packages/bcc/__pycache__/
python-bcc /usr/lib/python3.5/site-packages/bcc/__pycache__/__init__.cpython-35.pyc
python-bcc /usr/lib/python3.5/site-packages/bcc/__pycache__/libbcc.cpython-35.pyc
python-bcc /usr/lib/python3.5/site-packages/bcc/__pycache__/table.cpython-35.pyc
python-bcc /usr/lib/python3.5/site-packages/bcc/libbcc.py
python-bcc /usr/lib/python3.5/site-packages/bcc/table.py

Is your 'python' actually a link to python3 the way it's supposed to be? Something like this:

$ which python
/usr/bin/python
$ pacman -Qo /usr/bin/python
/usr/bin/python is owned by python 3.5.2-1

Here is the exact line used to build the child package:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=bcc#n73

All we're doing is passing the name of the interpreter over to the cmake file and it does the rest; it feels like it's accidentally finding your python2 instance instead of your python3 instance and building it incorrectly. Walk through the build steps in the PKGBUILD file manually and see if you can spot exactly where it's going wrong...

I just ran a makepkg here on it and confirm that I am not getting python2 library files in the python-bcc package, they are the python3 as expected.

==> Starting package_python-bcc()...
-- Revision is 0.1.8
-- Found LLVM: /usr/include
CMake Warning at tests/cc/CMakeLists.txt:10 (message):
Recommended test program 'netperf' not found


CMake Warning at tests/cc/CMakeLists.txt:14 (message):
Recommended test program 'iperf' not found


-- Configuring done
-- Generating done
-- Build files have been written to: /home/tengel/abs/bcc/src/bcc-0.1.8/build
[ 17%] Built target clang_frontend
[ 65%] Built target b_frontend
[ 95%] Built target bcc
[100%] Built target bcc_py
[100%] Built target bcc_py
Install the project...
-- Install configuration: "Release"
running install
running build
running build_py
running install_lib
creating /home/tengel/abs/bcc/pkg/python-bcc/usr
creating /home/tengel/abs/bcc/pkg/python-bcc/usr/lib
creating /home/tengel/abs/bcc/pkg/python-bcc/usr/lib/python3.5
creating /home/tengel/abs/bcc/pkg/python-bcc/usr/lib/python3.5/site-packages
creating /home/tengel/abs/bcc/pkg/python-bcc/usr/lib/python3.5/site-packages/bcc
copying build/lib/bcc/libbcc.py -> /home/tengel/abs/bcc/pkg/python-bcc/usr/lib/python3.5/site-packages/bcc
copying build/lib/bcc/__init__.py -> /home/tengel/abs/bcc/pkg/python-bcc/usr/lib/python3.5/site-packages/bcc
copying build/lib/bcc/table.py -> /home/tengel/abs/bcc/pkg/python-bcc/usr/lib/python3.5/site-packages/bcc
byte-compiling /home/tengel/abs/bcc/pkg/python-bcc/usr/lib/python3.5/site-packages/bcc/libbcc.py to libbcc.cpython-35.pyc
byte-compiling /home/tengel/abs/bcc/pkg/python-bcc/usr/lib/python3.5/site-packages/bcc/__init__.py to __init__.cpython-35.pyc
byte-compiling /home/tengel/abs/bcc/pkg/python-bcc/usr/lib/python3.5/site-packages/bcc/table.py to table.cpython-35.pyc
running install_egg_info
Writing /home/tengel/abs/bcc/pkg/python-bcc/usr/lib/python3.5/site-packages/bcc-0.1.8-py3.5.egg-info
==> Tidying install...
-> Removing libtool files...
-> Purging unwanted files...
-> Removing static library files...
-> Stripping unneeded symbols from binaries and libraries...
-> Compressing man and info pages...
==> Checking for packaging issue...
==> Creating package "python-bcc"...
-> Generating .PKGINFO file...
-> Generating .BUILDINFO file...
-> Generating .MTREE file...
-> Compressing package...

Make sure yours looks like the above.

bretthoerner commented on 2016-07-30 17:36

I had the issue that the other user mentioned when I used yaourt, I did it manually (used cower) and it worked fine.

For reference/Google:

Packages (4) bcc-0.1.8-2 bcc-tools-0.1.8-2 python-bcc-0.1.8-2 python2-bcc-0.1.8-2

Total Installed Size: 37.65 MiB

:: Proceed with installation? [Y/n]
(4/4) checking keys in keyring [########################################################################################] 100%
(4/4) checking package integrity [########################################################################################] 100%
(4/4) loading package files [########################################################################################] 100%
(4/4) checking for file conflicts [########################################################################################] 100%
error: failed to commit transaction (conflicting files)
/usr/lib/python2.7/site-packages/bcc-0.1.8-py2.7.egg-info exists in both 'python2-bcc' and 'python-bcc'
/usr/lib/python2.7/site-packages/bcc/__init__.py exists in both 'python2-bcc' and 'python-bcc'
/usr/lib/python2.7/site-packages/bcc/libbcc.py exists in both 'python2-bcc' and 'python-bcc'
/usr/lib/python2.7/site-packages/bcc/table.py exists in both 'python2-bcc' and 'python-bcc'
Errors occurred, no packages were upgraded.

troyengel commented on 2016-07-09 13:40

I went ahead and just added depends=('linux-headers') to the main BCC package, as to do anything meaningful with it (not just the provided examples) you need that installed. Thanks for the report, I'm working on updating bcc-git package as well.

codemac commented on 2016-07-09 00:44

None of the example work until you install kernel-headers.

Please add this to the dependencies of bcc-tools, if not bcc.

troyengel commented on 2016-06-19 17:44

I uninstalled my working versions, redownloaded (cower -d bcc), did a makepkg and installed without problems:

$ sudo pacman -U bcc-0.1.8-1-x86_64.pkg.tar.xz bcc-tools-0.1.8-1-x86_64.pkg.tar.xz python-bcc-0.1.8-1-x86_64.pkg.tar.xz python2-bcc-0.1.8-1-x86_64.pkg.tar.xz
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (4) bcc-0.1.8-1 bcc-tools-0.1.8-1 python-bcc-0.1.8-1
python2-bcc-0.1.8-1

Total Installed Size: 37.87 MiB

:: Proceed with installation? [Y/n]
(4/4) checking keys in keyring [######################] 100%
(4/4) checking package integrity [######################] 100%
(4/4) loading package files [######################] 100%
(4/4) checking for file conflicts [######################] 100%
(4/4) checking available disk space [######################] 100%
:: Processing package changes...
(1/4) installing bcc [######################] 100%
Optional dependencies for bcc
bcc-tools: Python utilites using the BCC library [pending]
python-bcc: Python 3 bindings for BCC [pending]
python2-bcc: Python 2 bindings for BCC [pending]
(2/4) installing bcc-tools [######################] 100%
Optional dependencies for bcc-tools
python-bcc: Python 3 bindings for BCC [pending]
python2-bcc: Python 2 bindings for BCC [pending]
(3/4) installing python-bcc [######################] 100%
(4/4) installing python2-bcc [######################] 100%


You'll need to post your exact error, my python2 and python3 don't seem to be conflicting.

chrisvest commented on 2016-06-15 08:58

This doesn't want to install because python 2 and python 3 are conflicting, apparently.