Package: src:linux
Version: 4.16.12-1
Severity: normal
[Copying Debian LVM team, but tentatively assigning this bug to the kernel.]
I've found that as of Linux 4.16, making traditional COW LVM2 snapshots
fails. (AFAICT, I can't substitute thin snapshots because my origin
volumes aren't thin and
gular DD who helps ensure that build errors for
packages that have recently emerged from NEW don't accidentally escape
notice.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
lately:
{standard input}: Assembler messages:
{standard input}:5854: Error: unrecognized opcode: `ptesync'
/<>/scripts/Makefile.build:319: recipe for target
'arch/powerpc/lib/sstep.o' failed
make[6]: *** [arch/powerpc/lib/sstep.o] Error 1
Could you please take a look?
Thanks!
--
A
Source: linux
Version: 4.11.11-1
Severity: grave
Justification: renders package unusable (uninstallable)
The recent binNMU of linux for Perl 5.26 broke the build-specific
headers packages, which are architecture-dependent but depend on an
identical *binary* version of the architecture-independent
Package: linux-libc-dev
Version: 3.11.10-1
Severity: important
Control: affects -1 src:trinity
Attempting to #include linux/btrfs.h without first ensuring a
definition of NULL (for instancy, by including stddef.h) fails:
/usr/include/linux/btrfs.h: In function 'btrfs_err_str':
Package: linux-kbuild-3.10
Version: 3.10-1
Severity: important
debian/build/scripts/mod/modpost passes getline pointers to
uninitialized name and name_len variables, leading to crashes under
some circumstances. According to getline's manpage, initializing name
to NULL should let the call
the modpost
binary under Valgrind to help track the problem down.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject
does
indeed add recordmcount.pl to linux-kbuild-3.5, thanks.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject
Ben Hutchings b...@decadent.org.uk writes:
It's pending for our version 2.6.39-3 and I've also submitted it to
sta...@kernel.org.
Great; thank you very much for identifying and incorporating it!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu
# Bcc:ing control@ once more
tags 627575 fixed-upstream
thanks
https://bugs.freedesktop.org/show_bug.cgi?id=37514#c3
claims that a fix has landed upstream, though I haven't had a chance to
confirm it.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu
left the moreinfo tag set for now in case you need
anything else from me.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
Package: linux-2.6
Version: 2.6.39-1
Severity: important
Since upgrading from 2.6.38-2 (Debian 2.6.38-5), I've found that, at
least on systems with integrated Intel graphics, loading the eeprom
module hangs indefinitely after reporting messages of the form
[drm] GMBUS timed out, falling back to
Package: linux-kbuild-2.6.32
Version: 2.6.32-1
Severity: important
Enabling CONFIG_FTRACE_MCOUNT_RECORD in the kernel's configuration calls
for the addition of recordmcount.pl to the set of scripts to install (as
listed in scripts/Makefile, AFAICT); could you please do so?
Thanks!
-- System
Package: linux-2.6
Version: 2.6.32-1
Severity: normal
I've been running into what appears to be the same problem since upgrading
to 2.6.32, in that vesafb is activating unsolicited (despite an explicit
video parameter referring to i915) and interfering with inteldrmfb:
[0.646467] vesafb:
Package: initramfs-tools
Version: 0.93.3
Severity: normal
Tags: patch
The i915 DRM module doubles as a framebuffer of sorts, at least in kernel
mode-setting setups; like its cousins intelfb and i810fb, it effectively
requires intel-agp despite not actually using any of its symbols. As
such,
Russ Allbery r...@debian.org writes:
Could you open a bug on the openafs package when you get a chance
(tomorrow or whenever) and we'll continue this there? It looks like
Filed as #521745. Kernel maintainers, apologies for the topic drift here.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu
Forwarding to Russ, who maintains a package that this change (which
came without warning TTBOMK) seriously inconveniences; please keep him
Cc:ed.
---BeginMessage---
severity 521515 wishlist
tags 521515 wontfix
thanks
On Fri, Mar 27, 2009 at 09:02:04PM -0400, Aaron M. Ucko wrote
headers; I'm not sure which specific headers would need
such treatment, but I suspect there are quite a few.
Please let me know if you'd like any other information.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger
, but I don't have
the new kbuild infrastructure installed anywhere yet.)
I should be able to do that, but I'm tired and on my way to bed, so
it'll have to wait until at least tomorrow.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http
Package: linux-headers-2.6.29-1-amd64
Version: 2.6.29-1
Severity: normal
Historically, /usr/src/linux-headers-VERSION-FLAVOR used to contain
symlinks into /usr/src/linux-headers-VERSION-common for anything not at
least potentially flavor-specific. As of 2.6.29-1, that no longer
holds, causing
Package: kernel
Severity: normal
Tags: patch upstream
The kernel's build system insists that users of x86_64 hardware use
AGP_INTEL_MCH rather than AGP_INTEL. However, the MCH driver supports
a far more limited range of hardware, and in particular fails to
support my system's i915G chipset. (I
21 matches
Mail list logo
