[PATCH] kernel-tools.spec: Adding libbpf package
by Jiri Olsa
hi,
please consider attached change that adds libbpf sub
package to be generated within kernel-tools spec.
We need libbpf in a separate package, starting with basic
files, some more might come later if there's a need.
thanks,
jirka
---
Packaging libbpf library, resulting in 3 packages:
libbpf
libbpf-devel
libbpf-debuginfo
$ rpm -qpl libbpf-5.1.0-0.rc3.git0.1.fc31.x86_64.rpm
/usr/lib/.build-id
/usr/lib/.build-id/da
/usr/lib/.build-id/da/34eb899cd9b325e75073da52cb12682a405910
/usr/lib64/libbpf.so.0
/usr/lib64/libbpf.so.0.0.2
/usr/share/licenses/libbpf
/usr/share/licenses/libbpf/COPYING
$ rpm -qpl libbpf-devel-5.1.0-0.rc3.git0.1.fc31.x86_64.rpm
/usr/include/bpf/bpf.h
/usr/include/bpf/btf.h
/usr/include/bpf/libbpf.h
/usr/lib64/libbpf.a
/usr/lib64/libbpf.so
/usr/share/licenses/libbpf-devel
/usr/share/licenses/libbpf-devel/COPYING
$ rpm -qpl libbpf-debuginfo-5.1.0-0.rc3.git0.1.fc31.x86_64.rpm
/usr/lib/debug
/usr/lib/debug/.build-id
/usr/lib/debug/.build-id/da
/usr/lib/debug/.build-id/da/34eb899cd9b325e75073da52cb12682a405910
/usr/lib/debug/.build-id/da/34eb899cd9b325e75073da52cb12682a405910.debug
/usr/lib/debug/usr
/usr/lib/debug/usr/lib64
/usr/lib/debug/usr/lib64/libbpf.so.0.0.2-5.1.0-0.rc3.git0.1.fc31.x86_64.debug
---
kernel-tools.spec | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/kernel-tools.spec b/kernel-tools.spec
index 0b1fd4438155..68b4f93ebc68 100644
--- a/kernel-tools.spec
+++ b/kernel-tools.spec
@@ -176,6 +176,19 @@ License: GPLv2
This package contains the bpftool, which allows inspection and simple
manipulation of eBPF programs and maps.
+%package -n libbpf
+Summary: The bpf library from kernel source
+License: GPLv2
+%description -n libbpf
+This package contains the kernel source bpf library.
+
+%package -n libbpf-devel
+Summary: Developement files for the bpf library from kernel source
+License: GPLv2
+%description -n libbpf-devel
+This package includes libraries and header files needed for development
+of applications which use bpf library from kernel source.
+
%prep
%setup -q -n kernel-%{kversion}%{?dist} -c
@@ -253,6 +266,9 @@ popd
pushd tools/bpf/bpftool
make
popd
+pushd tools/lib/bpf
+make V=1
+popd
# Build the docs
pushd tools/kvm/kvm_stat/
@@ -340,6 +356,9 @@ make DESTDIR=%{buildroot} prefix=%{_prefix} bash_compdir=%{_sysconfdir}/bash_com
# man-pages packages this (rhbz #1686954)
rm %{buildroot}%{_mandir}/man7/bpf-helpers.7
popd
+pushd tools/lib/bpf
+make DESTDIR=%{buildroot} prefix=%{_prefix} libdir=%{_libdir} V=1 install install_headers
+popd
###
### scripts
@@ -420,7 +439,23 @@ popd
%{_mandir}/man8/bpftool.8.gz
%license linux-%{kversion}/COPYING
+%files -n libbpf
+%{_libdir}/libbpf.so.0
+%{_libdir}/libbpf.so.0.0.2
+%license linux-%{kversion}/COPYING
+
+%files -n libbpf-devel
+%{_libdir}/libbpf.a
+%{_libdir}/libbpf.so
+%{_includedir}/bpf/bpf.h
+%{_includedir}/bpf/btf.h
+%{_includedir}/bpf/libbpf.h
+%license linux-%{kversion}/COPYING
+
%changelog
+* Tue Apr 02 2019 Jiri Olsa <jolsa(a)redhat.com> - 5.1.0-1.rc3.git0.1
+- Add libbpf, libbpf-devel and libbpf-debuginfo packages
+
* Mon Apr 01 2019 Jeremy Cline <jeremy(a)jcline.org> - 5.1.0-0.rc3.git0.1
- Linux v5.1-rc3
--
2.17.2
4 years, 11 months
[PATCH] configs: only visit generic/powerpc once
by Paul Bolle
The rule that generates kernel-ppc64le-debug.config visits
configs/generic/powerpc twice. Stop doing that.
Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl>
---
configs/config_generation | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/config_generation b/configs/config_generation
index 97683c517ef5..b3385fd1cff9 100644
--- a/configs/config_generation
+++ b/configs/config_generation
@@ -18,7 +18,7 @@ i686-debug=generic:generic-x86:generic-x86-i686:debug:debug-x86
# ppc64le
ppc64le=generic:generic-powerpc
-ppc64le-debug=generic:generic-powerpc:generic-powerpc:debug
+ppc64le-debug=generic:generic-powerpc:debug
# s390x
s390x=generic:generic-s390x
--
2.17.2
5 years
Call For Test Days for Fedora 31!
by Sumantro Mukherjee
Hi Fedora users, developers and friends!
It's time to start thinking about Test Days for Fedora 31.
For anyone who isn't aware, a Test Day is an event usually focused
around IRC for interaction and a Wiki page for instructions and results,
with the aim being to get a bunch of interested users and developers
together to test a specific feature or area of the distribution. You can
run a Test Day on just about anything for which it would be useful to do
some fairly focused testing in 'real time' with a group of testers; it
doesn't have to be code, for instance, we often run Test Days for
l10n/i18n topics. For more information on Test Days, see
https://fedoraproject.org/wiki/QA/Test_Days .
Anyone who wants to can host their own Test Day, or you can request that
the QA group helps you out with organization or any combination of the
two. To propose a Test Day, just file a ticket in fedora-qa pagure - here's
an example https://pagure.io/fedora-qa/issue/583 . For
instructions on hosting a Test Day, see
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management .
You can see the schedule at <goog_29817696>
https://pagure.io/fedora-qa/issues?tags=test+days .
There are many slots open right now. Consider the development schedule
<https://fedoraproject.org/wiki/Releases/31/Schedule>, though, in deciding
when
you want to run your Test Day - for some topics you may want to avoid
the time before the Beta release or the time after the feature freeze
or the Final Freeze.
We normally aim to schedule Test Days on Thursdays; however, if you want
to run a series of related Test Days, it's often a good idea to do
something like Tuesday / Wednesday / Thursday of the same week (this is
how we usually run the X Test Week, for instance). If all the Thursday
slots fill up but more people want to run Test Days, we will open up
Tuesday slots as overflows. And finally, if you really want to run a
Test Day in a specific timeframe due to the development schedule, but
the Thursday slot for that week is full, we can add a slot on another
day. We're flexible! Just put in your ticket the date or timeframe you'd
like, and we'll figure it out from there.
If you don't want to run your own Test Day, but you are willing to help
with another, feel free to join one or more of already accepted Test Days:
2019-04-30 Fedora Media Writer Test Day
GNOME Test Day
Silverblue Test Day*
i18n Test Day*
Kernel Test Week*
Upgrade Test Day*
And don't be afraid, there are lot of more slots available for your own
Test Day!
[*] These are the test days we run generally to make sure everything is
working fine, the dates get announced as we move into release cycle.
If you have any questions about the Test Day process, please don't
hesitate to contact me or any member of the Fedora QA team on test at
lists.fedoraproject.org or in #fedora-qa on IRC. Thanks!
Best Regards,
Sumantro
Fedora QE
--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED <https://redhat.com/trusted>
5 years
please remember to test F28 kernels
by Laura Abbott
F28 is seeing a pretty big fall off in karma for new kernels.
This is somewhat expected as we move towards F30 release.
If you happen to have an F28 system around, please remember
to test and give karma.
Thanks,
Laura
5 years, 1 month
Re: [PATCH] kernel-tools.spec: Adding libbpf package
by Jiri Olsa
On Tue, Apr 02, 2019 at 02:25:26PM +0200, Jesper Dangaard Brouer wrote:
> On Tue, 2 Apr 2019 12:35:10 +0200
> Jiri Olsa <jolsa(a)redhat.com> wrote:
>
> > We need libbpf in a separate package, starting with basic
> > files, some more might come later if there's a need.
> [...]
>
> > ---
> > Packaging libbpf library, resulting in 3 packages:
> > libbpf
> > libbpf-devel
> > libbpf-debuginfo
> >
> [...]
> > $ rpm -qpl libbpf-devel-5.1.0-0.rc3.git0.1.fc31.x86_64.rpm
> > /usr/include/bpf/bpf.h
> > /usr/include/bpf/btf.h
> > /usr/include/bpf/libbpf.h
>
> I'm using libbpf as a git-submodule, for my XDP-tutorial examples.
> https://github.com/xdp-project/xdp-tutorial/
>
> And it seems to match the "installed" include files this proj depend on:
>
> $ find libbpf/src/root/usr/include/ -type f
> libbpf/src/root/usr/include/bpf/bpf.h
> libbpf/src/root/usr/include/bpf/libbpf.h
> libbpf/src/root/usr/include/bpf/btf.h
>
> As you mention some more might come later, like xsk.h for AF_XDP.
>
>
> For my XDP-tutorial examples, I did end-up with some extra headers
> files that I copied from the kernel tree, and even modified a bit, for
> getting compiling working. BUT I'm not sure they belong in in the
> libbpf-devel.
>
> https://github.com/xdp-project/xdp-tutorial/tree/master/headers
>
> $ ls -1 headers/
> bpf_endian.h
> bpf_helpers.h
> bpf_util.h
> jhash.h
> perf-sys.h
ok, perhaps we should put all the needed helpers under libbpf
tree in the kernel sources first, and then we can package them
I dont like the idea of moving headers from distinct places
in kernel into libbpf include directory
jirka
5 years, 1 month
