Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #65964 > unrolled thread

Bug#948041: impossible to update libbpf without updating the kernel

Back to article view | Back to linux.debian.kernel

Contents

  Bug#948041: impossible to update libbpf without updating the kernel Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2020-01-03 18:20 +0100
    Bug#948041: impossible to update libbpf without updating the kernel Marco d'Itri <md@Linux.IT> - 2020-01-03 19:20 +0100
      Bug#948041: impossible to update libbpf without updating the kernel Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2020-01-03 19:50 +0100
      Bug#948041: impossible to update libbpf without updating the kernel Bastian Blank <bblank@thinkmo.de> - 2020-01-03 21:00 +0100
        Bug#948041: impossible to update libbpf without updating the kernel Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2020-01-03 21:30 +0100
          Bug#948041: impossible to update libbpf without updating the kernel Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2020-01-12 01:40 +0100
            Bug#948041: impossible to update libbpf without updating the kernel Bastian Blank <waldi@debian.org> - 2020-01-12 10:10 +0100
    Bug#948041: impossible to update libbpf without updating the kernel Jonathan Nieder <jrnieder@gmail.com> - 2020-01-15 07:20 +0100
      Bug#948041: impossible to update libbpf without updating the kernel Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2020-01-15 14:00 +0100
        Bug#948041: impossible to update libbpf without updating the kernel Bastian Blank <bblank@thinkmo.de> - 2020-01-18 16:50 +0100
          Bug#948041: impossible to update libbpf without updating the kernel Andrii Nakryiko <andrii.nakryiko@gmail.com> - 2020-01-20 07:50 +0100
        Bug#948041: impossible to update libbpf without updating the kernel Ben Hutchings <ben@decadent.org.uk> - 2020-01-31 17:20 +0100
          Bug#948041: impossible to update libbpf without updating the kernel Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2020-01-31 17:40 +0100
            Bug#948041: impossible to update libbpf without updating the kernel Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2020-02-05 22:10 +0100
    Bug#948041: marked as done (libbpf-dev: please build from  https://github.com/libbpf/libbpf) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2020-04-12 00:10 +0200

#65964 — Bug#948041: impossible to update libbpf without updating the kernel

Package: src:linux
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-kernel@lists.debian.org

libbpf source has moved to a separate github repo but keeps the kernel
as the true/first source, and updating github repo when release is ready.
In Steve's word the problem they faced is:

> The problem I'm now having is that I'm looking at fixing and updating
> some of the code in this library, and since library versioning is
> critical for applications that depend on it, we need to have a way to
> update the versions, and this does not correspond with the Linux
> versions.

So, looking at libbpf github repo at [1], I can see libbpf has already
released v0.0.6 but we only have v0.0.5 in Debian and there is no way
to update that unless the kernel is updated to v5.5+. And looking at
the kernel repo I can see libbpf people are working on v0.0.7. The full
discussion is at [2].

Do we package libbpf from their github repo independent of the kernel
update? Then we will need to remove the libbpf building bits from the
Debian kernel source and create a separate package for libbpf.
And so, it will be great if kernel team will like to package and maintain
it, if not, then I will be happy to do it. Please reject this bug report
if you think libbpf should not be done separately and should live inside
kernel source package.


[1]. https://github.com/libbpf/libbpf
[2]. https://lore.kernel.org/lkml/20200102234950.GA14768@krava/

--
Regards
Sudip

[toc] | [next] | [standalone]

#65965

[Multipart message — attachments visible in raw view] — view raw

On Jan 03, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:

> Do we package libbpf from their github repo independent of the kernel
> update? Then we will need to remove the libbpf building bits from the
> Debian kernel source and create a separate package for libbpf.
This is what some of the upstream libbpf developers requested us to do.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#65966

On Fri, Jan 3, 2020 at 6:15 PM Marco d'Itri <md@linux.it> wrote:
>
> On Jan 03, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>
> > Do we package libbpf from their github repo independent of the kernel
> > update? Then we will need to remove the libbpf building bits from the
> > Debian kernel source and create a separate package for libbpf.
> This is what some of the upstream libbpf developers requested us to do.

great. I guess there is no other bug report for this request and we
can use this bug to track that activity. I am not sure if the
kernel-team is aware of the request and if they agree with that. I
have added Ben in the upstream discussion for his comment.

I will do an initial packaging over the weekend unless you have
already done this or want to do the same.


-- 
Regards
Sudip

[toc] | [prev] | [next] | [standalone]

#65967

Hi Marco

On Fri, Jan 03, 2020 at 06:59:36PM +0100, Marco d'Itri wrote:
> On Jan 03, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> > Do we package libbpf from their github repo independent of the kernel
> > update? Then we will need to remove the libbpf building bits from the
> > Debian kernel source and create a separate package for libbpf.
> This is what some of the upstream libbpf developers requested us to do.

What I don't understand is, if the kernel git tree is the primary
location for this library, why should we use an external copy?

What are the benefits of doing so?

Bastian

-- 
The best diplomat I know is a fully activated phaser bank.
		-- Scotty

[toc] | [prev] | [next] | [standalone]

#65968

On Fri, Jan 3, 2020 at 7:49 PM Bastian Blank <bblank@thinkmo.de> wrote:
>
> Hi Marco
>
> On Fri, Jan 03, 2020 at 06:59:36PM +0100, Marco d'Itri wrote:
> > On Jan 03, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> > > Do we package libbpf from their github repo independent of the kernel
> > > update? Then we will need to remove the libbpf building bits from the
> > > Debian kernel source and create a separate package for libbpf.
> > This is what some of the upstream libbpf developers requested us to do.
>
> What I don't understand is, if the kernel git tree is the primary
> location for this library, why should we use an external copy?
>
> What are the benefits of doing so?

The only benefit will be that we will be able to update the libraries
irrespective of kernel update. libbpf v0.0.6 has been released in
December but we will not be able to move to that version. The
userspace application using this library is deprived of the benefit of
the fixes that v0.0.6 brings.


-- 
Regards
Sudip

[toc] | [prev] | [next] | [standalone]

#66060

X-Debbugs-Cc: debian-devel@lists.debian.org

On Fri, Jan 03, 2020 at 08:23:58PM +0000, Sudip Mukherjee wrote:
> On Fri, Jan 3, 2020 at 7:49 PM Bastian Blank <bblank@thinkmo.de> wrote:
> >
> > Hi Marco
> >
> > On Fri, Jan 03, 2020 at 06:59:36PM +0100, Marco d'Itri wrote:
> > > On Jan 03, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> > > > Do we package libbpf from their github repo independent of the kernel
> > > > update? Then we will need to remove the libbpf building bits from the
> > > > Debian kernel source and create a separate package for libbpf.
> > > This is what some of the upstream libbpf developers requested us to do.
> >
> > What I don't understand is, if the kernel git tree is the primary
> > location for this library, why should we use an external copy?
> >
> > What are the benefits of doing so?
> 
> The only benefit will be that we will be able to update the libraries
> irrespective of kernel update. libbpf v0.0.6 has been released in
> December but we will not be able to move to that version. The
> userspace application using this library is deprived of the benefit of
> the fixes that v0.0.6 brings.

Any thoughts on this please...

I have now done an initial packaging and can open an ITP if everyone
thinks we should move this out of debian kernel packaging.

And, I think I should also point out here that libtraceevent developers
are also moving to a separate repo which will have their final releases
rather then using the kernel repo. I will open a separate bug report for
them after they have decided where they want their new repo. And, libperf
might also follow suit after libtraceevent.

It might be better if we decide now what we want to do and tell them
accordingly.


--
Regards
Sudip

[toc] | [prev] | [next] | [standalone]

#66061

Hi Sudip

On Sun, Jan 12, 2020 at 12:28:20AM +0000, Sudip Mukherjee wrote:
> On Fri, Jan 03, 2020 at 08:23:58PM +0000, Sudip Mukherjee wrote:
> > > What are the benefits of doing so?
> > The only benefit will be that we will be able to update the libraries
> > irrespective of kernel update. libbpf v0.0.6 has been released in
> > December but we will not be able to move to that version. The
> > userspace application using this library is deprived of the benefit of
> > the fixes that v0.0.6 brings.

But updating independently does not provide any benefit.  As the kernel
repo is still upstream, all upstream chnages will flow into the Debian
archive.  An extra package will always lag behind, as changes needs to
flow from kernel to external repo.

> It might be better if we decide now what we want to do and tell them
> accordingly.

Why should we?  If the upstream developers decide to maintain it
independently, aka don't use the kernel repo as true source, or better,
remove the source from it, then we have something to do.

Bastian

-- 
The more complex the mind, the greater the need for the simplicity of play.
		-- Kirk, "Shore Leave", stardate 3025.8

[toc] | [prev] | [next] | [standalone]

#66089

retitle 948041 libbpf-dev: please build from https://github.com/libbpf/libbpf
reassign 948041 libbpf-dev
merge 942903 948041
quit

Hi,

Julia Kartseva wrote:
> On Sun, 12 Jan 2020 09:51:55 +0100 Bastian Blank <waldi@debian.org> wrote:

>> Why should we?  If the upstream developers decide to maintain it
>> independently, aka don't use the kernel repo as true source, or better,
>> remove the source from it, then we have something to do.

I agree --- if upstream development were happening in
https://github.com/libbpf/libbpf then this would be a no-brainer.  It
appears to instead be a mirror of the source that's in the kernel
repo, though.

> Why should we switch from kernel sources to GH is a frequently asked
> question so the reason was explained in libbpf README [1].

If I'm reading that correctly, the intent appears to be that it would
allow faster libbpf upgrades.

In the context of the Debian project, that could go both ways.  The
Linux kernel packages are very well maintained.  New versions appear
in stable-backports pretty quickly, and that's *less* likely to happen
with a separate libbpf source package.  Binary package dependencies do
not force an end user to use the same version of the kernel as
userspace tools like this one.  Debian even permits binary packages to
have different version numbers from the source package they were built
from.

Depending packages would likely use Debian's shlibs or symbols
mechanism (if upstream provides symbol versioning, that is very
helpful) to automatically produce appropriate dependencies.  More
details about this are at
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#dependencies-between-the-library-and-other-packages

So this appears to impose exactly the same costs and benefits as any
other instance where someone splits a binary package that comes from
the same upstream source package into a separate Debian source
package.  Sometimes that is the right thing to do, especially when the
Debian maintainers for the two packages do not work very closely
together.  Is that the case here?

Is there some underlying need that we could address more directly?
I think I'm missing some piece of the motivation here.

Thanks,
Jonathan

> [1] https://github.com/libbpf/libbpf#distributions

[toc] | [prev] | [next] | [standalone]

#66092

Hi Jonathan,

On Wed, Jan 15, 2020 at 06:12:05AM +0000, Jonathan Nieder wrote:
> retitle 948041 libbpf-dev: please build from https://github.com/libbpf/libbpf
> reassign 948041 libbpf-dev
> merge 942903 948041
> quit
> 
> Hi,
> 
> Julia Kartseva wrote:
> > On Sun, 12 Jan 2020 09:51:55 +0100 Bastian Blank <waldi@debian.org> wrote:
> 
> >> Why should we?  If the upstream developers decide to maintain it
> >> independently, aka don't use the kernel repo as true source, or better,
> >> remove the source from it, then we have something to do.
> 
> I agree --- if upstream development were happening in
> https://github.com/libbpf/libbpf then this would be a no-brainer.  It
> appears to instead be a mirror of the source that's in the kernel
> repo, though.

That will be difficult as all of them are dependent on the ftrace hooks
that are in the kernel.

> 
> > Why should we switch from kernel sources to GH is a frequently asked
> > question so the reason was explained in libbpf README [1].
> 
> If I'm reading that correctly, the intent appears to be that it would
> allow faster libbpf upgrades.

Yes, one of my intent. Faster and independent.

> 
> In the context of the Debian project, that could go both ways.  The
> Linux kernel packages are very well maintained.  New versions appear
> in stable-backports pretty quickly, and that's *less* likely to happen
> with a separate libbpf source package.  Binary package dependencies do
> not force an end user to use the same version of the kernel as
> userspace tools like this one.  Debian even permits binary packages to
> have different version numbers from the source package they were built
> from.

Agreed. I recently had to add libtraceevent which is also another one
in kernel source.

> 
> Depending packages would likely use Debian's shlibs or symbols
> mechanism (if upstream provides symbol versioning, that is very
> helpful) to automatically produce appropriate dependencies.  More
> details about this are at
> https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#dependencies-between-the-library-and-other-packages
> 
> So this appears to impose exactly the same costs and benefits as any
> other instance where someone splits a binary package that comes from
> the same upstream source package into a separate Debian source
> package.  Sometimes that is the right thing to do, especially when the
> Debian maintainers for the two packages do not work very closely
> together.  Is that the case here?

Absolutely no. Atleast not from my side. As said before I had the
opportunity to do the packaging for libtraceevent and I had all the
help and guidance from the kernel team.

> 
> Is there some underlying need that we could address more directly?
> I think I'm missing some piece of the motivation here.

Going back to the history of why I started this bug report. I was added
in a discussion about libtraceevent and Steven (upstream developer of
libtraceevent) was asking how can he make changes to the library without
releasing a new version and that the distros should not pick up as that
will still be premature and not tested enough. I could not suggest
anything as libtraceevent will be picked up autumatically when the next
kernel is packaged and as a result libtraceevent also, even though it
might still be in the development state. And at that point, Jiri Olsa
said that libbpf moved to github for this same reason.

So, here are my motivations for this bug report:
1) It will allow independent packaging.
2) It will not package something which is still in the middle of
development and not released yet by the developers.


--
Regards
Sudip

[toc] | [prev] | [next] | [standalone]

#66120

On Wed, Jan 15, 2020 at 12:50:16PM +0000, Sudip Mukherjee wrote:
> On Wed, Jan 15, 2020 at 06:12:05AM +0000, Jonathan Nieder wrote:
> > I agree --- if upstream development were happening in
> > https://github.com/libbpf/libbpf then this would be a no-brainer.  It
> > appears to instead be a mirror of the source that's in the kernel
> > repo, though.
> That will be difficult as all of them are dependent on the ftrace hooks
> that are in the kernel.

What will be difficult?

> > > Why should we switch from kernel sources to GH is a frequently asked
> > > question so the reason was explained in libbpf README [1].

Let's go through it one by one.

"Consistent versioning across distributions."

Maybe, but the kernel is also versioned consistently.

"No ties to any specific kernel, transparent handling of older kernels."

What?  Either they are upstream for it or patch the source.  But this
point means it can't be a direct mirror.  So what is it?

"Continuous integration testing via TravisCI."
"Static code analysis via LGTM and Coverity."

Both are not restricted to this repo.

> > If I'm reading that correctly, the intent appears to be that it would
> > allow faster libbpf upgrades.
> Yes, one of my intent. Faster and independent.

And how does it do that, without being upstream of the source?

Sorry, but I intend to end this discussion here.

Bastian

-- 
It would be illogical to assume that all conditions remain stable.
		-- Spock, "The Enterprise Incident", stardate 5027.3

[toc] | [prev] | [next] | [standalone]

#66161

On Sat, Jan 18, 2020 at 7:48 AM Bastian Blank <bblank@thinkmo.de> wrote:
>
> On Wed, Jan 15, 2020 at 12:50:16PM +0000, Sudip Mukherjee wrote:
> > On Wed, Jan 15, 2020 at 06:12:05AM +0000, Jonathan Nieder wrote:
> > > I agree --- if upstream development were happening in
> > > https://github.com/libbpf/libbpf then this would be a no-brainer.  It
> > > appears to instead be a mirror of the source that's in the kernel
> > > repo, though.
> > That will be difficult as all of them are dependent on the ftrace hooks
> > that are in the kernel.
>
> What will be difficult?
>
> > > > Why should we switch from kernel sources to GH is a frequently asked
> > > > question so the reason was explained in libbpf README [1].
>
> Let's go through it one by one.
>
> "Consistent versioning across distributions."
>
> Maybe, but the kernel is also versioned consistently.

Libbpf releases are only loosely synchronized with kernel releases,
and it's only due to current convention we established within
community. There is nothing preventing multiple releases of libbpf
between two releases of kernel. So having Linux distributions use
Github's release tags ensures that all of them are building from
exactly the same source code version.

> "No ties to any specific kernel, transparent handling of older kernels."
>
> What?  Either they are upstream for it or patch the source.  But this
> point means it can't be a direct mirror.  So what is it?

It is mostly a direct mirror, with some extra Github-specific stuff
beside (like Travis CI testing, etc). All the libbpf source code fixes
do go through bpf-next tree, though.

But the point here was that libbpf itself is not built with any
particular kernel version in mind. It is by design possible to use the
very latest libbpf against a pretty old kernel version and this will
work: libbpf will degrade some of the features (e.g, BTF type info
associations), but everything will keep working otherwise (unless user
requests feature that requires latest kernel version, of course: in
that case BPF program will fail to load and libbpf will return
corresponding error code).

>
> "Continuous integration testing via TravisCI."
> "Static code analysis via LGTM and Coverity."
>
> Both are not restricted to this repo.

Not sure what you mean by this. We can't have Travis CI integration w/
bpf-next source tree. But we can and we have it for Github mirror,
which runs tests and static analysis for every sync pull request. We
already have and are enhancing at the moment our testing set up to
test multiple kernels in multiple environments.

>
> > > If I'm reading that correctly, the intent appears to be that it would
> > > allow faster libbpf upgrades.
> > Yes, one of my intent. Faster and independent.
>
> And how does it do that, without being upstream of the source?
>
> Sorry, but I intend to end this discussion here.
>
> Bastian
>
> --
> It would be illogical to assume that all conditions remain stable.
>                 -- Spock, "The Enterprise Incident", stardate 5027.3
>
> --
> To unsubscribe, send mail to 948041-unsubscribe@bugs.debian.org.

[toc] | [prev] | [next] | [standalone]

#66275

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2020-01-15 at 12:50 +0000, Sudip Mukherjee wrote:
> Hi Jonathan,
> 
> On Wed, Jan 15, 2020 at 06:12:05AM +0000, Jonathan Nieder wrote:
> > retitle 948041 libbpf-dev: please build from https://github.com/libbpf/libbpf
> > reassign 948041 libbpf-dev
> > merge 942903 948041
> > quit
> > 
> > Hi,
> > 
> > Julia Kartseva wrote:
> > > On Sun, 12 Jan 2020 09:51:55 +0100 Bastian Blank <waldi@debian.org> wrote:
> > > > Why should we?  If the upstream developers decide to maintain it
> > > > independently, aka don't use the kernel repo as true source, or better,
> > > > remove the source from it, then we have something to do.
> > 
> > I agree --- if upstream development were happening in
> > https://github.com/libbpf/libbpf then this would be a no-brainer.  It
> > appears to instead be a mirror of the source that's in the kernel
> > repo, though.
> 
> That will be difficult as all of them are dependent on the ftrace hooks
> that are in the kernel.
> 
> > > Why should we switch from kernel sources to GH is a frequently asked
> > > question so the reason was explained in libbpf README [1].
> > 
> > If I'm reading that correctly, the intent appears to be that it would
> > allow faster libbpf upgrades.
> 
> Yes, one of my intent. Faster and independent.

This is a potential benefit, but probably only in the run-up to a
release when we might fix the kernel version early.

[...]
> > Is there some underlying need that we could address more directly?
> > I think I'm missing some piece of the motivation here.
> 
> Going back to the history of why I started this bug report. I was added
> in a discussion about libtraceevent and Steven (upstream developer of
> libtraceevent) was asking how can he make changes to the library without
> releasing a new version and that the distros should not pick up as that
> will still be premature and not tested enough.
[...]

However, this ability to release libbpf *less* often also seems
important, and I think this point has been missed.

I have some concern about whether this might prevent us building
bpftool in future (if it depends on recent changes in libbpf) but
that's hypothetical at this point.

So on balance I support moving libbpf out to a separate source package.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.

[toc] | [prev] | [next] | [standalone]

#66276

On Fri, Jan 31, 2020 at 4:11 PM Ben Hutchings <ben@decadent.org.uk> wrote:
>
> On Wed, 2020-01-15 at 12:50 +0000, Sudip Mukherjee wrote:
> > Hi Jonathan,
> >
> > On Wed, Jan 15, 2020 at 06:12:05AM +0000, Jonathan Nieder wrote:
> > > retitle 948041 libbpf-dev: please build from https://github.com/libbpf/libbpf
> > > reassign 948041 libbpf-dev
> > > merge 942903 948041
> > > quit
> > >
> > > Hi,
> > >
> > > Julia Kartseva wrote:
> > > > On Sun, 12 Jan 2020 09:51:55 +0100 Bastian Blank <waldi@debian.org> wrote:
> > > > > Why should we?  If the upstream developers decide to maintain it
> > > > > independently, aka don't use the kernel repo as true source, or better,
> > > > > remove the source from it, then we have something to do.
> > >
> > > I agree --- if upstream development were happening in
> > > https://github.com/libbpf/libbpf then this would be a no-brainer.  It
> > > appears to instead be a mirror of the source that's in the kernel
> > > repo, though.
> >
> > That will be difficult as all of them are dependent on the ftrace hooks
> > that are in the kernel.
> >
> > > > Why should we switch from kernel sources to GH is a frequently asked
> > > > question so the reason was explained in libbpf README [1].
> > >
> > > If I'm reading that correctly, the intent appears to be that it would
> > > allow faster libbpf upgrades.
> >
> > Yes, one of my intent. Faster and independent.
>
> This is a potential benefit, but probably only in the run-up to a
> release when we might fix the kernel version early.
>
> [...]
> > > Is there some underlying need that we could address more directly?
> > > I think I'm missing some piece of the motivation here.
> >
> > Going back to the history of why I started this bug report. I was added
> > in a discussion about libtraceevent and Steven (upstream developer of
> > libtraceevent) was asking how can he make changes to the library without
> > releasing a new version and that the distros should not pick up as that
> > will still be premature and not tested enough.
> [...]
>
> However, this ability to release libbpf *less* often also seems
> important, and I think this point has been missed.
>
> I have some concern about whether this might prevent us building
> bpftool in future (if it depends on recent changes in libbpf) but
> that's hypothetical at this point.

Since, bpftool will also be in userspace, so I am guessing that it
will also have the same problem as libbpf and the upstream developers
might again think of moving to github. But whatever is the case I am
sure we can think of something to fix that problem if it arises.

>
> So on balance I support moving libbpf out to a separate source package.

Thanks Ben.

As discussed, I will raise a merge request on the kernel repo to
remove libbpf building bits. And then use this bug to deliver the new
source package.


-- 
Regards
Sudip

[toc] | [prev] | [next] | [standalone]

#66316

Hi All,

On Fri, Jan 31, 2020 at 04:28:34PM +0000, Sudip Mukherjee wrote:
> On Fri, Jan 31, 2020 at 4:11 PM Ben Hutchings <ben@decadent.org.uk> wrote:
> >
> > On Wed, 2020-01-15 at 12:50 +0000, Sudip Mukherjee wrote:
> > > Hi Jonathan,
> > >
<snip>
> 
> >
> > So on balance I support moving libbpf out to a separate source package.
> 
> Thanks Ben.
> 
> As discussed, I will raise a merge request on the kernel repo to
> remove libbpf building bits. And then use this bug to deliver the new
> source package.

https://salsa.debian.org/kernel-team/linux/merge_requests/207 has been
opened to remove libbpf from kernel.
#950760 is the RFS for the new upload which has been packaged from github.

--
Regards
Sudip

[toc] | [prev] | [next] | [standalone]

#66733 — Bug#948041: marked as done (libbpf-dev: please build from https://github.com/libbpf/libbpf)

[Multipart message — attachments visible in raw view] — view raw

Your message dated Sat, 11 Apr 2020 22:00:23 +0000
with message-id <E1jNOAp-0005PY-16@fasolo.debian.org>
and subject line Bug#948041: fixed in libbpf 0.0.6-1
has caused the Debian Bug report #948041,
regarding libbpf-dev: please build from https://github.com/libbpf/libbpf
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
948041: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948041
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web