From: Jens Axboe <[email protected]>
To: Guillem Jover <[email protected]>, [email protected]
Subject: Re: liburing packaging issues
Date: Sat, 8 Feb 2020 13:02:15 -0700 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 2/8/20 10:36 AM, Guillem Jover wrote:
> Hi!
>
> Stefan Metzmacher asked whether I could package and upload liburing
> for Debian (and as a side effect Ubuntu). And here are some of the
> things I've noticed that would be nice to get fixed or improved
> before I upload it there.
>
> * The README states that the license is LGPL (I assume 2.1+ in
> contrast to 2.1?) and MIT, but there's at least one header that's
> GPL-2.0 + Linux-syscall-note, which I assume is due to it coming
> from the kernel headers. Would be nice to have every file with an
> explicit license grant, say at least with an SPDX tag, and update
> the README.
OK, I can clarify that and add SPDX headers.
> * From the RPM spec file and the debian packaging in the repo, I
> assume there is no actual release tarball (didn't see on in
> kernel.dk nor kernel.org)? It would be nice to have one with a
> detached OpenPGP signature, so that we can include it in the
> Debian source package, to chain and verify the provenance from
> upstream.
I do generate release tar balls with a detached signature, see:
https://brick.kernel.dk/snaps/
> * The test suite fails for me on the following unit tests:
>
> read-write accept-link poll-many poll-v-poll short-read send_recv
>
> while running on Linux 5.5.0-rc0. I read from the README it is not
> supposed to work on old kernels, and might even crash them. But it
> would still be nice if these tests would get SKIPPED, so that I can
> enable them unconditionally to catch possible regressions and so they
> do not make the package fail to build from source on the Debian build
> daemons due to too old kernels, which in most cases will be one from
> a Debian stable release (Linux 4.19.x or so).
The tests should build fine on any system, they just won't pass on any
system. So I don't think this is a packaging issue, don't run them as
part of building the package.
> There are a couple of issues with the build system, for which I'll be
> sending out a couple of patches later.
Thanks!
--
Jens Axboe
next prev parent reply other threads:[~2020-02-08 20:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-08 17:36 liburing packaging issues Guillem Jover
2020-02-08 20:02 ` Jens Axboe [this message]
2020-02-15 13:48 ` Guillem Jover
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox