Package: linux-headers-2.6.32-bpo.5-openvz-amd64
Version: 2.6.32-28~bpo50+1
Severity: normal
Hi,
i tryed to build and load a module running the kernel in version:
linux-image-2.6.32-bpo.5-openvz-amd64 2.6.32-23~bpo50+1
trying to load the module i get the following messages:
# modprobe drbd
FATAL
Processing commands for cont...@bugs.debian.org:
> reassign 606440 linux-2.6
Bug #606440 [linux-headers-2.6.32-bpo.5-openvz-amd64]
linux-headers-2.6.32-bpo.5-openvz-amd64: Modules build with this headers could
not be loaded on kernel (version 2.6.32-23~bpo50+1)
Warning: Unknown package 'linux-he
Your message dated Thu, 9 Dec 2010 10:18:16 +0100
with message-id <20101209091816.ga26...@wavehammer.waldi.eu.org>
and subject line Re: Bug#606440: linux-headers-2.6.32-bpo.5-openvz-amd64:
Modules build with this headers could not be loaded on kernel (version
2.6.32-23~bpo50+1)
has caused the Deb
After an upgrade, it seems to work. Bug can be closed :-).
--
Félix
signature.asc
Description: Digital signature
On Wed, Dec 08, 2010 at 09:35:50PM +, Asbjoern Sloth Toennesen wrote:
> Usefull if building for sparc64 userland, because the
> sparc and sparc64 userlands use the same 64-bit kernel,
> making it impossible to always select the correct userland
> architecture for the resulting debian package.
>
Usefull if building for sparc64 userland, because the
sparc and sparc64 userlands use the same 64-bit kernel,
making it impossible to always select the correct userland
architecture for the resulting debian package.
Might also be usefull, if you want a i386 userland with a amd64 kernel.
Example u
Hi
I'm seeing the same issue on r410. 2.6.32-28 with numa=noacpi doesn't
help though. Or isn't this yet in that kernel?
Thanks
Rudy
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: ht
On 12/09/2010 02:24 PM, maximilian attems wrote:
> On Wed, Dec 08, 2010 at 09:35:50PM +, Asbjoern Sloth Toennesen wrote:
>> Usefull if building for sparc64 userland, because the
>> sparc and sparc64 userlands use the same 64-bit kernel,
>> making it impossible to always select the correct userl
On 9.12.2010 16:24, Asbjoern Sloth Toennesen wrote:
> Usefull if building for sparc64 userland, because the
> sparc and sparc64 userlands use the same 64-bit kernel,
> making it impossible to always select the correct userland
> architecture for the resulting debian package.
>
> Might also be usef
On 12/09/2010 03:34 PM, Michal Marek wrote:
> On 9.12.2010 16:24, Asbjoern Sloth Toennesen wrote:
>> Usefull if building for sparc64 userland, because the
>> sparc and sparc64 userlands use the same 64-bit kernel,
>> making it impossible to always select the correct userland
>> architecture for the
Package: linux-image-2.6.32-5-amd64
Version: 2.6.32-28
Severity: normal
On this hardware:
00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA)
[1002:4383]
Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard [1043:836c]
Kernel driver in use: HDA Intel
01:05
Processing commands for cont...@bugs.debian.org:
> #
> # bts-link upstream status pull for source package linux-2.6
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> user bts-link-upstr...@lists.alioth.debian.org
Setting user to bts-link-upstr...@lists.alioth.debian
#
# bts-link upstream status pull for source package linux-2.6
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#
user bts-link-upstr...@lists.alioth.debian.org
# remote status report for #588782 (http://bugs.debian.org/588782)
# * http://bugzilla.openvz.org/show_bug.cgi
Here is a patch (against the ubuntu package, just as example)
which instead of doing a dumb retry loop, waits for udev.
=== modified file 'debian/changelog'
--- debian/changelog2010-04-26 15:17:47 +
+++ debian/changelog2010-12-08 21:44:32 +
@@ -1,3 +1,15 @@
+initramfs-tools (0.92bu
Package: linux-tools-2.6.36
Version: 2.6.36-1~experimental.1
Severity: serious
/usr/share/doc/linux-tools-2.6.36/copyright gives me the impression
that we have a license to distribute /usr/bin/perf_2.6.36 only under
the terms of the GPLv2. Is this correct?
It seems that perf_2.6.36 uses openssl:
On Thu, 2010-12-09 at 23:36 +0200, Timo Juhani Lindfors wrote:
> Package: linux-tools-2.6.36
> Version: 2.6.36-1~experimental.1
> Severity: serious
>
> /usr/share/doc/linux-tools-2.6.36/copyright gives me the impression
> that we have a license to distribute /usr/bin/perf_2.6.36 only under
> the t
Processing commands for cont...@bugs.debian.org:
> severity 606520 serious
Bug #606520 [linux-tools-2.6.36] linux-tools-2.6.36: /usr/bin/perf_2.6.36 links
against openssl but copyright lists only GPLv2 without exceptions
Ignoring request to change severity of Bug 606520 to the same value.
> thank
On Fri, 2010-12-10 at 03:36 +, Ben Hutchings wrote:
> On Thu, 2010-12-09 at 23:36 +0200, Timo Juhani Lindfors wrote:
> > Package: linux-tools-2.6.36
> > Version: 2.6.36-1~experimental.1
> > Severity: serious
> >
> > /usr/share/doc/linux-tools-2.6.36/copyright gives me the impression
> > that w
On Thu, 9 Dec 2010, Ben Hutchings wrote:
Please can you also add to that report that you got the same results
under 2.6.36.
Done. Following a suggestion from a responder on kernel.org an
eject/reload does allow the CDR to be verified as matching the original
ISO.
A reasonable workaroun
On Thu, 2010-12-09 at 21:52 -0700, loupga...@hethcote.com wrote:
>
> On Thu, 9 Dec 2010, Ben Hutchings wrote:
>
> >
> > Please can you also add to that report that you got the same results
> > under 2.6.36.
>
>
> Done. Following a suggestion from a responder on kernel.org an
> eject/reload doe
Probably you are the uploader of the following file(s) in
the Debian upload queue directory:
linux-2.6_2.6.37~rc5-1~experimental.1.diff.gz
linux-2.6_2.6.37~rc5-1~experimental.1.dsc
This looks like an upload, but a .changes file is missing, so the job
cannot be processed.
If no .changes file ar
Ben Hutchings writes:
> I have no idea what the upstream developers intended, they seem a bit
> clueless about distribution. I only just realised that they try to use
> libbfd (GPLv3, incompatible) even though perf can get the same
> functionality from libiberty (GPLv2)!
Hmm, are you planning to
Ben Hutchings writes:
> Since perf doesn't use any of the functionality in libssl via Python,
> I'm not convinced there's a problem here.
Good. Would it be appropriate to describe this in copyright file
though?
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject
linux-2.6_2.6.37~rc5-1~experimental.1_multi.changes uploaded successfully to
localhost
along with the files:
linux-2.6_2.6.37~rc5-1~experimental.1.dsc
linux-2.6_2.6.37~rc5.orig.tar.gz
linux-2.6_2.6.37~rc5-1~experimental.1.diff.gz
linux-support-2.6.37-rc5_2.6.37~rc5-1~experimental.1_all.deb
firmware-linux-free_2.6.37~rc5-1~experimental.1_all.deb
to main/l/linux-2.6/firmware-linux-free_2.6.37~rc5-1~experimental.1_all.deb
linux-2.6_2.6.37~rc5-1~experimental.1.diff.gz
to main/l/linux-2.6/linux-2.6_2.6.37~rc5-1~experimental.1.diff.gz
linux-2.6_2.6.37~rc5-1~experimental.1.dsc
to main
Package: xen-linux-system-2.6.32-5-xen-amd64
Version: 2.6.32-28
Severity: serious
Tags: squeeze
When upgrading a fully working server running the Lenny version of Xen,
with xen-linux-system-2.6.26-2-xen-amd64 installed, the xen-hypervisor
package isn't installed, and xen-linux-system-2.6.32-5-xen-
26 matches
Mail list logo
