The failure [1] message is:
[ 58%] Linking C shared library libbcc_bpf.so
cd /builddir/build/BUILD/bcc/src/cc && /usr/bin/cmake -E
cmake_link_script CMakeFiles/bpf-shared.dir/link.txt --verbose=1
/usr/bin/cc -fPIC -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_AS
Upstream has renamed it's lib to avoid conflict with libbpf.so from libbpf
project.
This change is included in the latest version 0.9.0. So if you depend on
this library, make sure to link against the new name.
$: dnf repoquery --disablerepo=\* --enablerepo=\*-source --arch src
--whatrequires bcc
Fixed smaclient.
Att.
--
Rafael Fonseca
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
On 23 January 2018 at 19:22, Ralph Bean wrote:
> On Tue, Jan 23, 2018 at 06:35:45PM +0100, Rafael dos Santos wrote:
> > I get this error after clicking the authorization link:
> >
> > [16450:16491:0123/182437.407698:ERROR:browser_gpu_
> channel_host_factory.cc(120)]
On 23 January 2018 at 18:20, Ralph Bean wrote:
I've removed the abicheck requirement from the greenwave policies for
> now until we know more:
> https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=
> 465f155d140a9fbe34f0f51dbfc2137b2900a6f8
>
Do we have to do anything to proceed
I get this error after clicking the authorization link:
[16450:16491:0123/182437.407698:ERROR:browser_gpu_channel_host_factory.cc(120)]
Failed to launch GPU process.
Created new window in existing browser session.
127.0.0.1 - - [23/Jan/2018 18:24:37] "GET
/?error_description=Unknown+client+ID&erro
- Original Message -
> On Fri, Aug 14, 2015 at 04:56:15AM -0400, Rafael dos Santos wrote:
> > - Original Message -
> >
> > > Currently, for arch-only issues which don't have an upstream fix
> > > our approach is to solve them at a packaging
- Original Message -
> Currently, for arch-only issues which don't have an upstream fix our approach
> is to solve them at a packaging level by disabling some part, be it tests,
> functionality, dependencies, etc.
>
> Unless we keep track of these kind of changes, we will only come across
Currently, for arch-only issues which don't have an upstream fix our approach
is to solve them at a packaging level by disabling some part, be it tests,
functionality, dependencies, etc.
Unless we keep track of these kind of changes, we will only come across them
again when a runtime error and/