Ext4-patch-queue rebased to 2.6.26-rc1?

Ext4-patch-queue rebased to 2.6.26-rc1?

[Gary Hawco]

Ted,

The latest patch in the queue errors out with "patch already applied"
error. I noticed that the patch from 073008/0301hrs GMT was rebased against
2.6.26-rc1, as opposed to what I think you meant, 2.6.27-rc1. I am sure
this is why the newest patch from today @ 0339hrs fails to patch the
2.6.27-rc1 kernel source cleanly.

Thanks,
Gary

P.S. I have a minor, weird problem involving midnight commander in both
Gentoo & Slackware that is also ext4-patch-queue related. The previous
patch I was using from 071508/2315hrs was fine. I didn't want to use the
git kernel, so I didn't update until the 072808/0005hrs GMT snapshot (Add
documentation re: mke2fs.conf label). This snapshot (and presumably all
newer ones add a continous row of symbols that resemble a nine (9) with a
longer tail to the border, top & bottom, left & right to mc in both Gentoo
& Slackware. This is while running in init3. It doesn't do it while running
in kde and opening a console and then starting mc.

I wanted to test the newest snapshot you posted to see if this problem
still exists, but again there is the patching problem.  I know there are
twelve patches between 071505/2315 & 072808/0005hrs, but I thought maybe
you an idea what would cause this mc corruption. Resetting the terminal in
init3 does not help.

Re: Ext4-patch-queue rebased to 2.6.26-rc1?

[Theodore Tso]

On Wed, Jul 30, 2008 at 09:46:39AM +0000, Gary Hawco wrote:
> 
> The latest patch in the queue errors out with "patch already applied"
> error. I noticed that the patch from 073008/0301hrs GMT was rebased against
> 2.6.26-rc1, as opposed to what I think you meant, 2.6.27-rc1. I am sure
> this is why the newest patch from today @ 0339hrs fails to patch the
> 2.6.27-rc1 kernel source cleanly.

That was a typo in the series file, which I have since fixed and
pushed out, but I didn't need to change any of the patches; the
patches all applied to a clean 2.6.27-rc1 kernel, at least when I was
using the 2.6.27-rc1 from git and using "guilt push -a" to apply the
patches (which is how I normally do thigs.)  Do you know which patch
was giving the "patch already applied" error; how are you applying the
patches?

There was a problem in the patch queue that wasn't fixed until "Add
missing patch, ext4__update_documentation..." where the patch queue
was *missing* a patch due to me fumble fingering a git commit.  Maybe
that's what you ran into?  It's since been fixed....

> P.S. I have a minor, weird problem involving midnight commander in both
> Gentoo & Slackware that is also ext4-patch-queue related. The previous
> patch I was using from 071508/2315hrs was fine. I didn't want to use the
> git kernel, so I didn't update until the 072808/0005hrs GMT snapshot (Add
> documentation re: mke2fs.conf label). This snapshot (and presumably all
> newer ones add a continous row of symbols that resemble a nine (9) with a
> longer tail to the border, top & bottom, left & right to mc in both Gentoo
> & Slackware. This is while running in init3. It doesn't do it while running
> in kde and opening a console and then starting mc.

Does that occur with 2.6.27-rc1 without the ext4 patch queue?  That
sounds like terminfo problem or maybe some kind of console font issue.

What happens if you are running with X, and switching to the VC
console via cotrol-alt-f1, and then logging into the VC console?  I'm
not seeing it when I run mc from a vt console on my Ubuntu system,
which I assume is the same as what you are seeing when are using mc
under init 3 on Slackware.

					- Ted