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
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
You can see the schedule at <goog_29817696>
There are many slots open right now. Consider the development schedule
<https://fedoraproject.org/wiki/Releases/31/Schedule>, though, in deciding
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
[*] 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!
TRIED AND PERSONALLY TESTED, ERGO TRUSTED <https://redhat.com/trusted>
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.
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.
> And it seems to match the "installed" include files this proj depend on:
> $ find libbpf/src/root/usr/include/ -type f
> 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
> $ ls -1 headers/
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