Apologies for the formatting of the prior message -- I was expecting
reportbug --bodyfile to either accept the message as-is or start an editor
after prepending the template. Its current behaviour seems entirely
unhelpful.
Anyway, possibly this is related to #867259 (or #867262, which seems to
Source: linux
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
*
Package: linux-headers-4.9.0-3-common-rt
Version: 4.9.30-1
Severity: wishlist
Dear Maintainer,
Using linux-headers-4.9.0-3-common-rt with lttng-modules-dkms causes a FTBFS
because the -rt and non-rt APIs are different.
lttng-modules-dkms includes a mechanism to auto-detect the use of -rt
So, I've checked upstream, and it looks like this is *partially*
fixed there, by these two commits:
https://bugs.lttng.org/projects/lttng-modules/repository/revisions/673e9a0300912e68d516cf06e0553c11b28cddbf/diff/instrumentation/events/lttng-module/sched.h
I'm reasonably sure that the solution to this requires adding an alternate
definition to instrumentation/events/lttmg-module/sched.h.
My first attempt was this:
#if (LTTNG_RT_VERSION_CODE >= LTTNG_RT_KERNEL_VERSION(4,9,27,18))
/*
* Tracepoint for showing priority inheritance modifying a tasks
Package: lttng-modules-dkms
Version: 2.9.0-1
Severity: important
Dear Maintainer,
Attempting to "apt install lttng-modules-dkms" in stretch results in a
successful build of the module for the non-rt kernel but a build error for the
rt kernel.
The make.log is included below.
-- System
At 06:27 p.m. 5/04/2017, Guido Günther wrote:
>> Also, according to
>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846016
>> this is no longer valid syntax and needs to be changed to
>> "debuild -- clean".
>
>Having a cleaner by default would force people
to set up two things
>if they want
Package: git-buildpackage
Version: 0.8.12.2
Severity: minor
Dear Maintainer,
"man gbp-buildpackage" seems to imply that "gbp buildpackage" will issue
"debuild clean" by default. It doesn't actually do so; it calls
/bin/true instead.
Also, according to
After further investigation, this appears to be upstream bug
https://bugs.freedesktop.org/show_bug.cgi?id=80553, which was fixed in
http://cgit.freedesktop.org/plymouth/commit/?id=84eb4381db85877a9a56b35994e6
c10d43e46ebe, which in turn is part of upstream Plymouth 0.9.2.
I have confirmed that
Package: plymouth
Version: 0.9.0-9
I have a Raspberry Pi 2B+ that was previously running Rasbian Wheezy with
Plymouth 0.8.5 on kernel 3.18.13-v7+ (armhf-v7l), and this was working as
expected. After upgrading this device to Raspbian Jessie, plymouth no
longer operates correctly. (The system
On Sat, 30 Aug 2014 23:27:47 +0200 Michael Prokop m...@debian.org wrote:
* Laurent Bigonville [Fri Aug 01, 2014 at 03:55:17PM +0200]:
An idea on how this could be fixed? In Ubuntu they have added a panic
hook to initramfs-tools that is being called in the panic() function.
Do you
This further patch (against 2.4.7 sources) is also required to get JS to not
crash and burn on armhf (Raspberry Pi):
--- a/debian/rules 2014-12-01 03:10:49.0 +
+++ b/debian/rules 2014-12-03 05:26:26.0 +
@@ -57,7 +57,7 @@
endif
# disable jit on some
12 matches
Mail list logo
