I am using Slackware 13.1. The current version e2fsprogs installed in my system is 1.41.11. I did bash-4.1# e2fsck -V. And the result was like this:
e2fsck 1.41.11 (14-Mar-2010)
Using EXT2FS Library version 1.41.11, 14-Mar-2010
Can anybody help me how to update it. Actually I've downloaded linux-2.6.37.2.tar.bz2 from kernel.org. I'm trying to compile this kernel. So I'm trying to update e2fsprogs.

I have also downloaded e2fsprogs-1.41.14.tar.gz.

e2fsprogs 1.41.14 is in Current, you can try using the SlackBuild to make a package for 13.1:
http://slackware.mirrors.tds.net/pub...e/a/e2fsprogs/

The kernel's ext* drivers don't depend on e2fsprog.

Yes the SlackBuild method mentioned should work. I was wondering though, does the new kernel need the newer e2fsprogs version for something, as your wording implies this, or do you just feel like it?

According to the documentation/changes file:

o Gnu C 3.2 # gcc --version
o Gnu make 3.80 # make --version
o binutils 2.12 # ld -v
o util-linux 2.10o # fdformat --version
o module-init-tools 0.9.10 # depmod -V
o e2fsprogs 1.41.4 # e2fsck -V
o jfsutils 1.1.3 # fsck.jfs -V
o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs
o xfsprogs 2.6.0 # xfs_db -V
o squashfs-tools 4.0 # mksquashfs -version
o btrfs-progs 0.18 # btrfsck
o pcmciautils 004 # pccardctl -V
o quota-tools 3.09 # quota -V
o PPP 2.4.0 # pppd --version
o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version
o nfs-utils 1.0.5 # showmount --version
o procps 3.2.0 # ps --version
o oprofile 0.9 # oprofiled --version
o udev 081 # udevinfo -V
o grub 0.93 # grub --version
o mcelog 0.6
o iptables 1.4.2 # iptables -V

So I'm trying to update all of these.

Your currently installed 1.41.11 is newer than 1.41.4, so I see no need to update e2fsprogs just to run this kernel.

The newer version is e2fsprogs-1.41.14.
And I have 1.41.11

yes, the newest is .14, but the changes file you quoted lists a minimum version requirement of .4 and .11 is higher than .4 so you don't *have* to update it,
If you want to update to .14 for the sake of it then that's fine. What myself and bgeddy were suggesting is that it's not a requirement.

Given all of the information uncovered in this thread, it seems that we are ignoring the proverbial elephant in the room: why do you need a custom kernel?

2.6.33.4 as included in 13.1 is old enough now to no longer be receiving upstream bugfixes. Personally, I think it's a very valid target for a local update on security gounds and not at all elephant shaped. But that's just me.

If that's his reasoning, sure - not elephant shaped at all.

It's also why I'm so glad 13.2 will be staying with the long-term .35.y branch. It'll mean I won't have to worry about building custom kernels when 13.2 releases. I can let Pat do all the work.

Well...

1) Just because a long-term kernel is released doesn't mean Pat will be building it.
2) He *could* ship 2.6.38 with 13.2; after all, 2.6.38 should be releasing relatively soon...

;-D

I personally would like that: X would be happy too

and, btw, I still hope there will be a slackware 13.37

Fair point. If there's no sign of a release candidate before .38 then that's probably a good choice. I'd just like to avoid the situation we had with 13.1, where it's kernel was abandoned by upstream right after the Slackware Release. Can't fault Pat for this though, it's the random nature of upstream that make things difficult.