2.5 changeset 1.952.4.2 corrupt in fs/jfs/inode.c

2.5 changeset 1.952.4.2 corrupt in fs/jfs/inode.c

Post by Pavel Mache » Mon, 10 Feb 2003 13:10:04



Hi!

Quote:> > > Note, I'm using my own GPL software to checkout from the bitkeeper
> > > servers (I don't want to miss the additional information stored in

> > Are you going to put up copy of that sw somewhere? I guess more people
> > are interested...

> Two things:

> 1) We're going to make a CVS archive of Linus tree available, automatically
>    updated, and we'll rsync it to some public place like kernel.org so you
>    can get at the data in a way you want with no BK involved at all.

I like that.
                                                                Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

2.5 changeset 1.952.4.2 corrupt in fs/jfs/inode.c

Post by Andrea Arcangel » Mon, 10 Feb 2003 16:20:10



> Hi!

> > > > Note, I'm using my own GPL software to checkout from the bitkeeper
> > > > servers (I don't want to miss the additional information stored in

> > > Are you going to put up copy of that sw somewhere? I guess more people
> > > are interested...

> > Two things:

> > 1) We're going to make a CVS archive of Linus tree available, automatically
> >    updated, and we'll rsync it to some public place like kernel.org so you
> >    can get at the data in a way you want with no BK involved at all.

> I like that.

Yes. This way the information will be stored in a open standard and
downloadable with an open protocol in real time. The backup of the CVS
repository to kernel.org maybe is enough once per month or less. It is
only meant to be 100% sure not to lose the whole critical info, losing
one month would be nothing compared to losing it all. And at the same
time Linus and others can keep using bitkeeper if they can agree with
its proprietary licence.

I'm sorry Larry has to do all the work to setup the CVS checkins by
himself, I wish I could help him, that would be more than fair, just let
me know if I can contribute in any way with the setup.

As for the format of the checkins I suggested Larry to tag the tree with
an unique ID (changeset number is ok if it's unique and it doesn't
change on the bk side, but we don't care too much about the tag name)
after every checkin of a changeset. The cvs tags will be equivalent to
the changesets in bitkeeper. For the metadata belonging to the checkin I
suggested filling the cvs log this way:

ChangeSet: xxxx
Date: xxx
Author: xxx
Files: [ 'fs/inode.c', 'fs/dquote.c' ]
xxxxxComments herexxxx
xxxxxxxxxx
xxxxxxxxx
xxxx

(unsure if the changeset line is really needed, also unsure about the
files line when files are deleted)

So it will be trivial to extract the whole metadata, shall we need to
feed it in another database, or shall we need to automate searching
function on the information provided in CVS.

A simple `cvs log COPYING` will show all the changesets. A cvs rdiff
between two cvs tags will show the files involved and their revision
numbers, a cvs log will tell us the changeset metadata between these two
revision numbers that is effectively the metadata belonging to the whole
changesets. It's not the most handy format if your object is to extract
the data, but this way we won't need to reinvent the wheel for doing the
checkouts and diffs against Linus's tree that should be by far the
common usage, so it makes sense to me, especially because this format is
just designed to be efficient in doing the checkouts of the tree so it
will be safe to use for Larry's internet connection.

One detail is that the tree will be linearized (the last bit I needed to
make bkweb really useful), in the sense the old checkins in branched
bk trees, will showup as an unique changeset in the CVS, and it will
showup always as the head revision in CVS. I think it should be fine
since it will effectively match the way Linus merge stuff, i.e. a bk
pull will generate a single changeset in CVS.

The first priority is not to risk losing information on the evolution of
Linux, and this will be achieved this way, so I'm very happy! :)

Thanks.

Andrea

PS. if Larry don't want to risk paying an higher internet bill for the
future CVS users that right now obviously have to download from
kernel.org (and also because CVS is more network hungry than than bk I
believe), I'm sure various organizations (I could imagine osdl.org for
istance) could offer to host the kernel CVS tree too and Larry would
only need to pay the upload of the few kbytes of the checkins, without
paying for the plenty mbytes downloads. It obviously makes no difference
to the CVS users, this is definitely up to Larry.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

2.5 changeset 1.952.4.2 corrupt in fs/jfs/inode.c

Post by Kenneth Johansso » Mon, 10 Feb 2003 20:40:11




> > We can go buy another machine for glibc2.3

> Buy a machine?  Why not use UML?

For something as simple as this you do not need anything more than
chroot so one box should do for all linux(glibc) versions.

But something more like vmware is needed if you also want to have window
and all the other X86 OS on the same box at the same time.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

2.5 changeset 1.952.4.2 corrupt in fs/jfs/inode.c

Post by Jamie Lokie » Fri, 14 Feb 2003 04:00:06



> 1) We're going to make a CVS archive of Linus tree available, automatically
>    updated, and we'll rsync it to some public place like kernel.org so you
>    can get at the data in a way you want with no BK involved at all.

Why not rsync the SCCS tree and let others worry about format
conversions?  Presumably that would be much less work.  (I'm
presuming, I know).

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

2.5 changeset 1.952.4.2 corrupt in fs/jfs/inode.c

Post by Jamie Lokie » Fri, 14 Feb 2003 04:00:18



> Why not rsync the SCCS tree and let others worry about format
> conversions?  Presumably that would be much less work.  (I'm
> presuming, I know).

Sorry if the tone of that seemed a bit harsh.

I mean that it might be less work for Larry to just mirror the SCCS tree
which Bitkeeper itself maintains - less overhead for Bitmover.

Just a suggestion.

cheers,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. 2.5 changeset 1.952.4.2 corrupt in fs/jfs/inode.c

Hello Larry,

If you apply all changeset in order starting from 2.5.59 until 1.952.4.2
you should get a fs/jfs/inode.c like this:

void jfs_truncate(struct inode *ip)
{
        jFYI(1, ("jfs_truncate: size = 0x%lx\n", (ulong) ip->i_size));

        block_truncate_page(ip->i_mapping, ip->i_size, jfs_get_block);
        ^^^^^^^^^^^^^^^^^^^

but the changeset 1.952.4.2 is the below one and it shows:

 void jfs_truncate(struct inode *ip)
 {
-       jFYI(1, ("jfs_truncate: size = 0x%lx\n", (ulong) ip->i_size));
+       jfs_info("jfs_truncate: size = 0x%lx", (ulong) ip->i_size);

        nobh_truncate_page(ip->i_mapping, ip->i_size);
        ^^^^^^^^^^^^^^^^^^

so it thinks the function is called nobh_truncate_page and not
block_truncate_page.

Note, I'm using my own GPL software to checkout from the bitkeeper
servers (I don't want to miss the additional information stored in
proprietary form inside the bitkepper database and so I'm extracting it
all and storing it in a open manner locally, in a complete structured
form, they're live classes dumped to disk, not like the monolithic
patches in the cset/ directory where it's not trivial to manage all the
metadata to see all the evolution of a certain file or subsystem by
writing a few more lines of code that loads and use those classes) so it
could be my bug and not a bug in bitkeeper, no idea if it's reproducible
with bitkeeper.  I hope I'm not wasting your time and that it's not a
bug from my part ;)

btw, the changeset would apply anyways despite the corrupted patch, if
I'd use the default fuzz level of patch, but still it looks corrupted
and a bug that needs fixing (either from my part or your part) so I'm
not going to ignore it even if it doesn't literally reject.

See:


I'd appreciate if you could check why bitkeeper thinks such function is
nobh_truncate_page and not block_truncate_page as my GPL software
pretends while it checkouts all the changesets from the bitkeeper
servers.

Thanks,

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. kernel 2.6 + sound problem

3. 2.5-bk K&R to ANSI conversions for fs/jfs/jfs_dmap.c and jfs_xtree.c

4. Compression on DataGeneral AViiON 4100

5. fs/inode.c sync fix and fs/ext2/inode.c tidy

6. I've the PCMCIA blues...

7. 2.4.12 -- Unresolved symbols in fs/jfs/jfs.o: block_flushpage

8. RedHat 5.2 eth0 problem

9. [2.5] reiserfs changeset 9 of 15 for 2.5.21

10. [2.5] reiserfs changeset 15 of 15 for 2.5.21

11. [2.5] reiserfs changeset 2 of 15 for 2.5.21

12. [2.5] reiserfs changeset 14 of 15 for 2.5.21

13. [2.5] reiserfs changeset 7 of 15 for 2.5.21