There are disparities between your recently accepted upload and the
override file for the following file(s):
unionfs-modules-2.6-486_2.6.18-7+etch2_i386.deb: package says section is admin,
override says misc.
unionfs-modules-2.6-686_2.6.18-7+etch2_i386.deb: package says section is admin,
overrid
Mapping testing to testing-proposed-updates.
Accepted:
gspca-modules-2.6-486_2.6.18-7+etch2_i386.deb
to
pool/main/l/linux-modules-extra-2.6/gspca-modules-2.6-486_2.6.18-7+etch2_i386.deb
gspca-modules-2.6-686-bigmem_2.6.18-7+etch2_i386.deb
to
pool/main/l/linux-modules-extra-2.6/gspca-modules-
linux-modules-extra-2.6_2.6.18-7+etch2_i386.changes uploaded successfully to
localhost
along with the files:
linux-modules-extra-2.6_2.6.18-7+etch2.dsc
linux-modules-extra-2.6_2.6.18-7+etch2.tar.gz
gspca-modules-2.6.18-4-486_2.6.18+01.00.04-7+etch2_i386.deb
gspca-modules-2.6-486_2.6.18-7+e
On Sat, Mar 31, 2007 at 07:22:38PM +0200, maximilian attems wrote:
> any voices against basing trunk on latest upstream?
> have an i386 working tree to commit.
>
> should 2.6.20 first be copied to sid?
The etch kernel is frozen, right, and will never be updated, so there is
nothing stopping us fr
Steve Langasek wrote:
> Well, there's no reason that someone can't use iommu=soft when booting the
> installer, as well. So perhaps it would be best to clone that bug and
> include this information in the installation guide or errata?
>
Yes that's a good idea.
I assume it would be also a probl
On Sat, Mar 31, 2007 at 07:59:44PM +0200, Christoph Anton Mitterer wrote:
> Andreas Barth wrote:
> > BTW, we intended to have frequent kernel uploads to proposed-updates,
> > and frankly speaking, I personally don't mind to already have a newer
> > kernel in proposed-updates during the release, but
Processing commands for [EMAIL PROTECTED]:
> tags 412132 + pending
Bug#412132: cacct interface misscalced about 100 TB
Tags were: patch
Tags added: pending
>
End of message, stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(administrat
Hi Bastian,
On Sat, Mar 31, 2007 at 04:05:33PM +0200, Bastian Blank wrote:
> On Thu, Mar 22, 2007 at 01:15:31AM -0700, Steve Langasek wrote:
> > In the meantime, I don't see any reason why we shouldn't patch the kernel to
> > disable hw iommu on nvidia systems only. I believe the attached patch
>
On Sat, Mar 31, 2007 at 03:58:49AM -0700, Steve Langasek wrote:
> On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote:
>
> > As I've told you in my email before I just tested your patch with the
> > following results (used linux-source-2.6.18 (2.6.18.dfsg.1-12) from
> > testin
maximilian attems <[EMAIL PROTECTED]> writes:
> any voices against basing trunk on latest upstream?
> have an i386 working tree to commit.
>
> should 2.6.20 first be copied to sid?
I would appreciate to have it uploaded at least to experimental before
moving to .21.
Just my 2c
--
O T
> From: maximilian attems
> Subject: 2.6.21-rc5
> Date: Sat, 31 Mar 2007 19:22:38 +0200
>
> any voices against basing trunk on latest upstream?
I'm running it nearly five days. I'm on amd64, without sysfs, did some
dvd burning, playing music have strange random glitches (maybe some
more NO_HZ prob
On Sat, Mar 31, 2007 at 08:18:26PM +0200, Andreas Barth wrote:
> * Sven Luther ([EMAIL PROTECTED]) [070331 16:03]:
> > The ideal would have been a framework where we could build new kernels and
> > have it integrated within a few days only. I gave a speach about this at
> > FOSDEM, of how we could
Your message dated Sat, 31 Mar 2007 21:06:12 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#416952: linux-image-2.6.18-4-686: Time is one hour too
fast when timezone is set to PST and hardware clock is synced with GMT
has caused the attached Bug report to be marked as done.
This m
Your message dated Sat, 31 Mar 2007 20:50:36 +0200
with message-id <[EMAIL PROTECTED]>
and subject line issue solved
has caused the attached Bug report 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 reo
Processing commands for [EMAIL PROTECTED]:
> # Automatically generated email from bts, devscripts version 2.10.2
> forcemerge 416519 416520
Bug#416519: linux-source-2.6.18: Suggests non-existant package ncurses-dev
Bug#416520: linux-source-2.6.18: Suggests non-existant package libncurses-dev
Forci
Your message dated Sat, 31 Mar 2007 20:41:37 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Issue solved
has caused the attached Bug report 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 reo
Package: linux-image-2.6.18-4-686
Version: 2.6.18.dfsg.1-11
Severity: minor
When my hardware clock is set to GMT and software wise my timezone is set to
"Los Angeles", my clock is always one hour too fast.
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (990, 'te
* Sven Luther ([EMAIL PROTECTED]) [070331 16:03]:
> The ideal would have been a framework where we could build new kernels and
> have it integrated within a few days only. I gave a speach about this at
> FOSDEM, of how we could use the initramfs incremental nature, to separate
> fully the kernel mo
Andreas Barth wrote:
> BTW, we intended to have frequent kernel uploads to proposed-updates,
> and frankly speaking, I personally don't mind to already have a newer
> kernel in proposed-updates during the release, but that's something I
> want to have signed-off by Martin.
The main problem with the
any voices against basing trunk on latest upstream?
have an i386 working tree to commit.
should 2.6.20 first be copied to sid?
--
maks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Thu, Mar 22, 2007 at 01:15:31AM -0700, Steve Langasek wrote:
> In the meantime, I don't see any reason why we shouldn't patch the kernel to
> disable hw iommu on nvidia systems only. I believe the attached patch
> should do this. Are you in a position to confirm that this does disable hw
> iom
On Sat, Mar 31, 2007 at 03:11:09PM +0200, Andreas Barth wrote:
> * Steve Langasek ([EMAIL PROTECTED]) [070331 12:59]:
> > On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote:
> > > I would say (although I'm by any means not kernel expert) that your
> > > patch looks good and I
* Steve Langasek ([EMAIL PROTECTED]) [070331 12:59]:
> On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote:
> > I would say (although I'm by any means not kernel expert) that your
> > patch looks good and I _strongly_ recommend to include it in etch r0 (!!)...
> > You're the re
Steve Langasek wrote:
> But regardless, there are no plans
> for another kernel update before etch r0, and including one is likely to
> delay the release. I'm of the opinion that this bug does not justify a
> delay at this point.
>
Uhm, sad to hear this...
> With the consent of the kernel
Package: linux-image-2.6.18-4-686
Version: 2.6.18.dfsg.1-11
Severity: important
The xircom_tulip_cb has been completely configured out of the debian
2.6.18 kernel (to the point it's not even commented out in the
/boot/config-2.6.18-4-686 file), presumably as it is sometimes thought
it has been dep
On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote:
> As I've told you in my email before I just tested your patch with the
> following results (used linux-source-2.6.18 (2.6.18.dfsg.1-12) from
> testing, of course on an amd64 system):
> - The patch applies without problems
26 matches
Mail list logo
