From: J. R. Okajima
Thorsten Glaser:
> Please send patches that _should_ apply against what=E2=80=99s in Debian.
> I don=E2=80=99t have time to play the merge game at the moment.
Which version of debian?
As you might know, the aufs module in the debian stable squeeze is out
of my control.
Anyway
From: J. R. Okajima
The pr_fmt macro is defined in fs/aufs/Makefile and it refers to the
AUFS_NAME macro, which caused a compilation error in m68k architecture.
Also it refers to the "current" macro which will be a problem too.
See-also: http://sourceforge.net/mailarchive/message.php?msg_id=2860
From: J. R. Okajima
By the previous commit,
8dc5387 2012-01-03 aufs: bugfix, headers 1/2, where the pr_fmt macro definition
several header file inclusion in other files became unnecessary.
Signed-off-by: J. R. Okajima
---
fs/aufs/branch.c |1 -
fs/aufs/branch.h |2 --
fs/aufs/cpup.c
Processing commands for cont...@bugs.debian.org:
> block 651092 with 588200
Bug #651092 [god] god: Process events not working due to missing kernel features
Was not blocked by any bugs.
Added blocking bug(s) of 651092: 588200
> thanks
Stopping processing here.
Please contact me if you need assist
Quick side question:
Sarah Sharp wrote:
> Yeah, don't try to blacklist xhci-hcd. It's not useful.
How else do you suggest that people figure out whether symptoms are
produced by the xhci-hcd driver or something else? However, I agree
that it's not useful _any more_, since Mathieu tried that te
On Wed, Dec 28, 2011 at 06:11:14PM +0100, Mathieu Malaterre wrote:
> On Thu, Dec 22, 2011 at 8:52 PM, Sarah Sharp
> wrote:
> > On Thu, Dec 22, 2011 at 04:18:56PM +0100, Mathieu Malaterre wrote:
> >> On Fri, Dec 16, 2011 at 11:27 AM, Jonathan Nieder
> >> wrote:
> >> System: Dell System Vostro 375
sf...@users.sourceforge.net dixit:
>Hold it please.
OK.
>I am going to make more changes. So it is better to git-pull and test
>the aufs GIT repository.
Please send patches that _should_ apply against what’s in Debian.
I don’t have time to play the merge game at the moment.
>> I have the same
Thorsten Glaser:
> Hrm, okay. I=E2=80=99ll try your patch then, once we get that register_cpu
> issue solved too. I=E2=80=99ll get back to you with test results.
Hold it please.
I am going to make more changes. So it is better to git-pull and test
the aufs GIT repository.
It will be released in t
#
# 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 #652708 (http://bugs.debian.org/652708)
# Bug title: linux-image-2.6-openvz-amd64: C
sf...@users.sourceforge.net dixit:
>- AUFS_NAME is necessary for both of kernel-space and user-space.
>- from userspace, users include aufs_type.h. to keep the consistency,
> aufs_type.h should include aufs_name.h.
>- for kernelspace, to put aufs_name.h _before_ all other headers.
Hrm, okay. I’l
On Mon, 2012-01-02 at 00:41 +, Ben Hutchings wrote:
> As I suggested a while back, radeon really doesn't work without firmware
> on some chips.
[...]
This (commit 77e00f2ea94abee1ad13bdfde19cf7aa25992b0e) is changing
behaviour for the BTC chips (codenames Barts, Turks and Caicos; model
numbers
Currently the value reported for max_batch_time is really the
value of min_batch_time.
Reported-by: Russell Coker
Signed-off-by: Ben Hutchings
---
fs/ext4/super.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 3e1329e..410e993 1
Thorsten Glaser:
> Then, why include it in the Makefile at all?
> (Or, why include aufs_name.h from aufs_type.h?)
- AUFS_NAME is necessary for both of kernel-space and user-space.
- from userspace, users include aufs_type.h. to keep the consistency,
aufs_type.h should include aufs_name.h.
- for
On Mon, 2012-01-02 at 23:41 +1100, Russell Coker wrote:
> Package: linux-2.6
> Version: 3.0.0-6
> Severity: normal
>
> According to mount(*) the max_batch_time parameter for mounting an ext4
> filesystem has a default value of 15000. When I try using it with values
> of 1 and 2 it appears
sf...@users.sourceforge.net dixit:
>> You include aufs_name.h twice now, once in the Makefile,
>> once in the header. Shouldn=E2=80=99t one be enough?
>
>No, because aufs_type.h is exported to userspace.
Then, why include it in the Makefile at all?
(Or, why include aufs_name.h from aufs_type.h?)
Thorsten Glaser:
> This doesn=E2=80=99t really differ from what I sent last,
> does it?
I am afraid you may not understand the important parts.
- the order of the definition and sched.h.
- no undef.
> >+#ifdef __KERNEL__
>
> Hrm. Is this needed?
Indeed necessary since aufs_name.h is exported t
Processing commands for cont...@bugs.debian.org:
> found 654206 3.1.6-1
Bug #654206 [linux-2.6] linux-image-3.0.0-2-amd64: max_batch_time doesn't seem
to work
There is no source info for the package 'linux-2.6' at version '3.1.6-1' with
architecture ''
Unable to make a source version for version
Package: linux-2.6
Version: 3.0.0-6
Severity: normal
According to mount(*) the max_batch_time parameter for mounting an ext4
filesystem has a default value of 15000. When I try using it with values
of 1 and 2 it appears to not work:
# mount -o loop,max_batch_time=1 test /mnt/tmp
# gr
sf...@users.sourceforge.net dixit:
>This is the last version of my approach (documentations are omitted).
This doesn’t really differ from what I sent last,
does it?
>Would you try on your m68k when you have time?
You _are_ aware that a kernel compile takes over a day, right?
Why don’t you use t
19 matches
Mail list logo
