Oh, now there is a worse problem.  See this new repo that I uploaded at
"2009-10-31.04:37:32"?  When I pull all patches from that new one into the old
one, I get the following failure:

HACK Wonwin-McBrootles-Computer:~/playground/pycryptopp/pycryptopp$ time darcs
pull -a -v -v -v zooko@192.168.1.100:playground/pycryptopp/pycryptopp

They have the following patches to pull:
Fri Oct 30 16:27:09 MDT 2009  zooko@zooko.com
  * aes: add pycryptopp.cipher.aes.start_up_self_test() which runs some quick
tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after the import
pycryptopp and before they use it.
Fri Oct 30 22:06:26 MDT 2009  zooko@zooko.com
  * rsa: add pycryptopp.publickey.rsa.start_up_self_test() which runs some quick
tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after they import
pycryptopp and before they use it.
Fri Oct 30 22:15:41 MDT 2009  zooko@zooko.com
  * sha256: add pycryptopp.cipher.sha256.start_up_self_test() which runs some
quick tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after they import
pycryptopp and before they use it.
Fri Oct 30 22:26:25 MDT 2009  zooko@zooko.com
  * ecdsa: add pycryptopp.publickey.ecdsa.start_up_self_test() which runs some
quick tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after they import
pycryptopp and before they use it.
Fri Oct 30 22:29:39 MDT 2009  zooko@zooko.com
  * ecdsa: fix a bug in the one of the unit tests which caused it to not-test
what it was supposed to
Getting and merging the following patches:
Fri Oct 30 16:27:09 MDT 2009  zooko@zooko.com
  * aes: add pycryptopp.cipher.aes.start_up_self_test() which runs some quick
tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after the import
pycryptopp and before they use it.
Fri Oct 30 22:06:26 MDT 2009  zooko@zooko.com
  * rsa: add pycryptopp.publickey.rsa.start_up_self_test() which runs some quick
tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after they import
pycryptopp and before they use it.
Fri Oct 30 22:15:41 MDT 2009  zooko@zooko.com
  * sha256: add pycryptopp.cipher.sha256.start_up_self_test() which runs some
quick tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after they import
pycryptopp and before they use it.
Fri Oct 30 22:26:25 MDT 2009  zooko@zooko.com
  * ecdsa: add pycryptopp.publickey.ecdsa.start_up_self_test() which runs some
quick tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after they import
pycryptopp and before they use it.
Fri Oct 30 22:29:39 MDT 2009  zooko@zooko.com
  * ecdsa: fix a bug in the one of the unit tests which caused it to not-test
what it was supposed to
Applying to pristine... Fri Oct 30 16:27:09 MDT 2009  zooko@zooko.com
  * aes: add pycryptopp.cipher.aes.start_up_self_test() which runs some quick
tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after the import
pycryptopp and before they use it.
Fri Oct 30 22:06:26 MDT 2009  zooko@zooko.com
  * rsa: add pycryptopp.publickey.rsa.start_up_self_test() which runs some quick
tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after they import
pycryptopp and before they use it.
Fri Oct 30 22:15:41 MDT 2009  zooko@zooko.com
  * sha256: add pycryptopp.cipher.sha256.start_up_self_test() which runs some
quick tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after they import
pycryptopp and before they use it.
Fri Oct 30 22:26:25 MDT 2009  zooko@zooko.com
  * ecdsa: add pycryptopp.publickey.ecdsa.start_up_self_test() which runs some
quick tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after they import
pycryptopp and before they use it.

darcs failed:  Error applying hunk to file ./pycryptopp/test/test_ecdsa.py
Fri Oct 30 22:29:39 MDT 2009  zooko@zooko.com
  * ecdsa: fix a bug in the one of the unit tests which caused it to not-test
what it was supposed to

real    0m13.603s
user    0m0.070s
sys     0m0.053s

And here is the stdout and stderr when doing that same pull with -v -v -v
--debug --timing.  Note that I had an earlier version of some of those patches
in this repo -- I subsequently obliterated them from this repo and amended them
in that repo.  Also actually for some of them I may have amended them in this
repo before pushing them to that repo and then obliterating them in this repo.

Attachments

• zooko.log.txt

Zooko, the problem with the R files in your repository with new darcs is
because this "pycryptopp.egg-info" directory is marked as boring. I guess this
is a bug in my new code where boring takes preference over what's already in
the repo. I'll investigate on how to fix that.

As for the other problem with unapplicable patches, that's reasonable given
that you have different patches in the branches under the same names. This
either tends to lead to "bug in get_extra" or unapplicable hunks (or both).
That's why the documentation says that you should never amend published
patches.

"As for the other problem with unapplicable patches, that's reasonable given
that you have different patches in the branches under the same names. This
either tends to lead to "bug in get_extra" or unapplicable hunks (or both).
That's why the documentation says that you should never amend published
patches."

It seems to me that darcs ought to give a clearer error message in the case of
different patches under the same name.  But, that's not what is happening, see:

HACK Wonwin-McBrootles-Computer:~/playground/pycryptopp/pycryptopp$ time darcs
push --dry-run
Would push to "zooko@192.168.1.100:playground/pycryptopp/pycryptopp"...
No recorded local changes to push!

real    0m13.964s
user    0m0.046s
sys     0m0.039s
HACK Wonwin-McBrootles-Computer:~/playground/pycryptopp/pycryptopp$ time darcs
pull --dry-run
Would pull from "zooko@192.168.1.100:playground/pycryptopp/pycryptopp"...
Would pull the following changes:
Fri Oct 30 16:27:09 MDT 2009  zooko@zooko.com
  * aes: add pycryptopp.cipher.aes.start_up_self_test() which runs some quick
tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after the import
pycryptopp and before they use it.

Fri Oct 30 22:06:26 MDT 2009  zooko@zooko.com
  * rsa: add pycryptopp.publickey.rsa.start_up_self_test() which runs some quick
tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after they import
pycryptopp and before they use it.

Fri Oct 30 22:15:41 MDT 2009  zooko@zooko.com
  * sha256: add pycryptopp.cipher.sha256.start_up_self_test() which runs some
quick tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after they import
pycryptopp and before they use it.

Fri Oct 30 22:26:25 MDT 2009  zooko@zooko.com
  * ecdsa: add pycryptopp.publickey.ecdsa.start_up_self_test() which runs some
quick tests and raises an exception if they fail
  This was suggested by "Practical Cryptography" (2nd edition) by Ferguson,
Schneier, and Kohno.  Now that we've had several different bugs in pycryptopp
that this would have caught, I've decided it is a good idea.  Users of
pycryptopp are advised to execute start_up_self_test() once after they import
pycryptopp and before they use it.

Fri Oct 30 22:29:39 MDT 2009  zooko@zooko.com
  * ecdsa: fix a bug in the one of the unit tests which caused it to not-test
what it was supposed to

Making no changes:  this is a dry run.

real    0m14.121s
user    0m0.045s
sys     0m0.037s

In all cases so far the pwd repo is the one that I uploaded at
2009-10-31.04:35:35 and the remote repo is the one that I uploaded at
2009-10-31:04:37:32.

Copy of issue1659

I'm confused by this: why does Zooko have different patches under the same patch
info?  Wouldn't amending change the date?  Doesn't the patch salt mechanism from
issue27 prevent this?

Could somebody provide answers to the above questions?

I can't!

kowey wrote: "I'm confused by this: why does Zooko have different patches under
the same patch info?  Wouldn't amending change the date?  Doesn't the patch salt
mechanism from issue27 prevent this?"

I don't have multiple patches under the same patch info -- all three versions of
the patch have different timestamps and Ignore-This salts:

HACK yukyuk:~/playground/pycryptopp/X/pycryptopp/_darcs$ time zgrep -A2 "fix a
bug in the one of the unit tests which"  *
hashed_inventory:[ecdsa: fix a bug in the one of the unit tests which caused it
to not-test what it was supposed to
hashed_inventory:zooko@zooko.com**20091031042939
hashed_inventory: Ignore-this: eef97738c0669fd44313be6c02dc5e74

real    0m0.302s
user    0m0.048s
sys     0m0.186s
HACK yukyuk:~/playground/pycryptopp/X/pycryptopp/_darcs$ cd patches/
HACK yukyuk:~/playground/pycryptopp/X/pycryptopp/_darcs/patches$ time zgrep -A2
"fix a bug in the one of the unit tests which"  *
0000000291-e1cdda90fe564a338d1a918150cf2a805d7cd365406e221f14257e701f507d50:[ecdsa:
fix a bug in the one of the unit tests which caused it to not-test what it was
supposed to
0000000291-e1cdda90fe564a338d1a918150cf2a805d7cd365406e221f14257e701f507d50:zooko@zooko.com**20091031042649
0000000291-e1cdda90fe564a338d1a918150cf2a805d7cd365406e221f14257e701f507d50:
Ignore-this: 2d5f069034c569e457063e0a3170b67a
0000000451-d79652e268e995b51de296784e082e4eebc7b19fc9cec444823670a503470d95:[ecdsa:
fix a bug in the one of the unit tests which caused it to not-test what it was
supposed to
0000000451-d79652e268e995b51de296784e082e4eebc7b19fc9cec444823670a503470d95:zooko@zooko.com**20091031042830
0000000451-d79652e268e995b51de296784e082e4eebc7b19fc9cec444823670a503470d95:
Ignore-this: 14b3277639ae5e4dafe719dd9f91c65b
0000000470-381ace4f21b0f4ddb3df7f1e8378aad572f2867656853897b1fdb84b7d290867:[ecdsa:
fix a bug in the one of the unit tests which caused it to not-test what it was
supposed to
0000000470-381ace4f21b0f4ddb3df7f1e8378aad572f2867656853897b1fdb84b7d290867:zooko@zooko.com**20091031042939
0000000470-381ace4f21b0f4ddb3df7f1e8378aad572f2867656853897b1fdb84b7d290867:
Ignore-this: eef97738c0669fd44313be6c02dc5e74
unrevert:[ecdsa: fix a bug in the one of the unit tests which caused it to
not-test what it was supposed to
unrevert:zooko@zooko.com**20091031042939
unrevert: Ignore-this: eef97738c0669fd44313be6c02dc5e74

real    0m28.856s
user    0m8.705s
sys     0m17.609s

You can verify by inspecting the pycryptopp.7z file that I uploaded
2009-10-31.04:37:32.

For future research,  I've taken the liberty of removing the remote version of
Zooko's repo, and uploading a minimal patch bundle (just the one offending
patch) in its place.

You can still reproduce the error with darcs apply.

Zooko: this kind of minimalisation can be help speed things up a bit, in the
future ;-)

Others: if for any reason, you need the remote repo, check the history of this
ticket.  It's still linked from there.

Attachments

• ecdsa_-fix-a-bug-in-the-one-of-the-unit-tests-which-caused-it-to-not_test-what-it-was-supposed-to.dpatch

Actually, I take it back! Zooko was perfectly right to have uploaded file681
(sorry!)

I did a darcs check in that repo and it turns out to be inconsistent.  So one
the one hand, the problem is simple: we're pulling a patch from a bad repo.

$ darcs check
Looks like we have a difference...                                              
Difference:  hunk ./pycryptopp/test/test_ecdsa.py 144
+        

Inconsistent repository!

On the other hand, we still have the question of how this bad repo came to be...
how exactly are we getting this extra whitespace in the bad repo?

Okay, I'll try to make minimal repos in the future.

When I do a darcs check in those repos I get a different error message: "error
applying hunk to file", same as when I pull the offending patch.  This is with
darcs-2.3.1+all-patches-up-to-yesterday.

Hm, some of the patches in this repository were generated by tailor (the patches
inside the "cryptopp" subdirectory), and maybe they were generated badly. 
However, "test_ecdsa.py" has never been touched by any tool but emacs/vim and darcs.

I'm doing an experiment of converting the entire repo from hashed-format to
darcs-2-format.  Is that a good idea?  I'll post to this ticket once that is done.

First: One thing you should do is to save a copy of the corrupted repo
(perhaps your file681 is good enough) and to try to repair the
corruption.

Darcs repair may not enough to do the job, unfortunately.  You may have
to pull all the good patches and then fix the rest by hand.  We can
schedule an appointment over IRC if you need help with this.

On Mon, Jan 11, 2010 at 17:39:27 +0000, Zooko wrote:
> Hm, some of the patches in this repository were generated by tailor (the patches
> inside the "cryptopp" subdirectory), and maybe they were generated badly. 
> However, "test_ecdsa.py" has never been touched by any tool but emacs/vim and darcs.

So in the corrupted repo, there is one extra whitespace line after this
one:

        s2 = verifier.serialize()

The line has some initial whitespace followed by a newline, which looks
very much like something made with a text editor.

The question is how this whitespace got there in the first place.
I'm not really sure how to pursue this line of inquiry.  Do you have
any ideas?  Does the line of whitespace ring any bells?

One hypothesis is that it got introduced through pristine corruption.
Do you know if there was a time when this repository was using an
old-fashioned format?

For what it's worth, I think the earliest patch which may be based
on the corrupted repo is 

Wed Jun 17 22:10:44 BST 2009  zooko@zooko.com
  * ecdsa: disable ECDSA so that nobody starts to rely on it (the current version works, but isn't ready for long-term support)

> I'm doing an experiment of converting the entire repo from hashed-format to
> darcs-2-format.  Is that a good idea?  I'll post to this ticket once that is done.

No, I think that would confuse matters.

In general, I don't really like a big push for people to switch already
existing repos to the darcs-2 format.  New repos, fine.  But if you've
already got an old repo and you're not actually too concerned about
exponential merge issues (eg you have a small team), then there really
isn't THAT much to gain for the amount of pain involved (you should
definitely be using hashed, though).

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

I'm pretty sure I was not using an old-fashioned format repository in the time
frame where that patch was written.  I think I manually edited that file with 
vi to remove trailing whitespace and then darcs amend'ed it.

Hey why do I have two files in _darcs/patches with different patch ids and the
same "Ignore-this:"?

HACK yukyuk:~/playground/pycryptopp/pycryptopp/_darcs/patches$ grep -A2
"disable ECDSA so" *
0000003679-92bb97d3bcba9b53a2bdfa5e6ffd1e9550c2d8a08c0ec891deb6fa6cf5b68bf5:
works, but isn't ready for long-term support)
0000003679-92bb97d3bcba9b53a2bdfa5e6ffd1e9550c2d8a08c0ec891deb6fa6cf5b68bf5-
0000003679-92bb97d3bcba9b53a2bdfa5e6ffd1e9550c2d8a08c0ec891deb6fa6cf5b68bf5-
Ignore-this: be45aafeded8e5ecaa8b61457f012741
--
0000004212-4a261603078f9642da899751ce6da13fc457e215838778d533c3a5f9d7bdbee9:
works, but isn't ready for long-term support)
0000004212-4a261603078f9642da899751ce6da13fc457e215838778d533c3a5f9d7bdbee9-
0000004212-4a261603078f9642da899751ce6da13fc457e215838778d533c3a5f9d7bdbee9-
Ignore-this: be45aafeded8e5ecaa8b61457f012741

Was there a bug in darcs in the (recent) past such that "amend-record" would
fail to change the Ignore-This?  Is there still such a bug?

Oh, and look the hashed_inventory says that one of these patches is something
else -- a tag that was recorded four days later:

HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
grep -A2 "disable ECDSA so" *
0000003679-92bb97d3bcba9b53a2bdfa5e6ffd1e9550c2d8a08c0ec891deb6fa6cf5b68bf5:
works, but isn't ready for long-term support)
0000003679-92bb97d3bcba9b53a2bdfa5e6ffd1e9550c2d8a08c0ec891deb6fa6cf5b68bf5-
0000003679-92bb97d3bcba9b53a2bdfa5e6ffd1e9550c2d8a08c0ec891deb6fa6cf5b68bf5-
Ignore-this: be45aafeded8e5ecaa8b61457f012741
--
0000004212-4a261603078f9642da899751ce6da13fc457e215838778d533c3a5f9d7bdbee9:
works, but isn't ready for long-term support)
0000004212-4a261603078f9642da899751ce6da13fc457e215838778d533c3a5f9d7bdbee9-
0000004212-4a261603078f9642da899751ce6da13fc457e215838778d533c3a5f9d7bdbee9-
Ignore-this: be45aafeded8e5ecaa8b61457f012741
--
unrevert:[ecdsa: disable ECDSA so that nobody starts to rely on it (the current
version works, but isn't ready for long-term support)
unrevert-zooko@zooko.com**20090617211044
unrevert- Ignore-this: be45aafeded8e5ecaa8b61457f012741
HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
grep -B3 -Ee"92bb97d3bcba9b53a2bdfa5e6ffd1e9550c2d8a08c0ec891deb6fa6cf5b68bf5|
../hashed_inventory-zooko@zooko.com**20090617211044
../hashed_inventory- Ignore-this: be45aafeded8e5ecaa8b61457f012741
../hashed_inventory-]
../hashed_inventory:hash:
0000003679-92bb97d3bcba9b53a2bdfa5e6ffd1e9550c2d8a08c0ec891deb6fa6cf5b68bf5
--
../hashed_inventory-zooko@zooko.com**20090621213654
../hashed_inventory- Ignore-this: 9e3be63ac03e1c2b9b9ae8fba4d49686
../hashed_inventory-]
../hashed_inventory:hash:
0000004212-4a261603078f9642da899751ce6da13fc457e215838778d533c3a5f9d7bdbee9
HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
grep -B4 -Ee"92bb97d3bcba9b53a2bdfa5e6ffd1e9550c2d8a08c0ec891deb6fa6cf5b68bf5|
../hashed_inventory-[ecdsa: disable ECDSA so that nobody starts to rely on it
(the current version works, but isn't ready for long-term support)
../hashed_inventory-zooko@zooko.com**20090617211044
../hashed_inventory- Ignore-this: be45aafeded8e5ecaa8b61457f012741
../hashed_inventory-]
../hashed_inventory:hash:
0000003679-92bb97d3bcba9b53a2bdfa5e6ffd1e9550c2d8a08c0ec891deb6fa6cf5b68bf5
--
../hashed_inventory-[TAG pycryptopp-0.5.14
../hashed_inventory-zooko@zooko.com**20090621213654
../hashed_inventory- Ignore-this: 9e3be63ac03e1c2b9b9ae8fba4d49686
../hashed_inventory-]
../hashed_inventory:hash:
0000004212-4a261603078f9642da899751ce6da13fc457e215838778d533c3a5f9d7bdbee9

Oh, and look, there are also two different patches for that tag with the same
Ignore-This and patch-id:

HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
grep -A2 "pycryptopp-0.5.14" *
0000000812-3ebd0107cf4074b0c6d5a4270c5ee857e95a5071a5a89c1790fde2a8424257c0:
0000000812-3ebd0107cf4074b0c6d5a4270c5ee857e95a5071a5a89c1790fde2a8424257c0-
0000000812-3ebd0107cf4074b0c6d5a4270c5ee857e95a5071a5a89c1790fde2a8424257c0-
Ignore-this: 9e3be63ac03e1c2b9b9ae8fba4d49686
--
0000004212-4a261603078f9642da899751ce6da13fc457e215838778d533c3a5f9d7bdbee9:
0000004212-4a261603078f9642da899751ce6da13fc457e215838778d533c3a5f9d7bdbee9-
0000004212-4a261603078f9642da899751ce6da13fc457e215838778d533c3a5f9d7bdbee9-
Ignore-this: 9e3be63ac03e1c2b9b9ae8fba4d49686
--
unrevert:[TAG pycryptopp-0.5.14
unrevert-zooko@zooko.com**20090621213654
unrevert- Ignore-this: 9e3be63ac03e1c2b9b9ae8fba4d49686

I don't remember for sure, but I think I might have used
unrecord/obliterate/amend-record on that tag.

Oh and look, hashed_inventory thinks that one of those two tags is something
else: a different tag that was made a couple of weeks later:

HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
grep -B4 -Ee"3ebd0107cf4074b0c6d5a4270c5ee857e95a5071a5a89c1790fde2a8424257c0|
../hashed_inventory-[TAG pycryptopp-0.5.14
../hashed_inventory-zooko@zooko.com**20090621213654
../hashed_inventory- Ignore-this: 9e3be63ac03e1c2b9b9ae8fba4d49686
../hashed_inventory-]
../hashed_inventory:hash:
0000004212-4a261603078f9642da899751ce6da13fc457e215838778d533c3a5f9d7bdbee9
--
../hashed_inventory-[TAG pycryptopp-0.5.15
../hashed_inventory-zooko@zooko.com**20090705194216
../hashed_inventory- Ignore-this: 363bb3b96b701befb5a8ebb47c5949ad
../hashed_inventory-]
../hashed_inventory:hash:
0000000812-3ebd0107cf4074b0c6d5a4270c5ee857e95a5071a5a89c1790fde2a8424257c0

Oh and I see that there are again patches with the same timestamp+IgnoreThis
but different patchids which think they are that tag:

HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
grep -A2 "pycryptopp-0.5.15" *
0000000812-3ebd0107cf4074b0c6d5a4270c5ee857e95a5071a5a89c1790fde2a8424257c0:
0000000812-3ebd0107cf4074b0c6d5a4270c5ee857e95a5071a5a89c1790fde2a8424257c0-
0000000812-3ebd0107cf4074b0c6d5a4270c5ee857e95a5071a5a89c1790fde2a8424257c0-
Ignore-this: 363bb3b96b701befb5a8ebb47c5949ad
--
0000001125-0b8d2729da1dc3f12ce537cf551ec4d7cb7896c825731e7683f5c64dcf8f52fd:
0000001125-0b8d2729da1dc3f12ce537cf551ec4d7cb7896c825731e7683f5c64dcf8f52fd-
0000001125-0b8d2729da1dc3f12ce537cf551ec4d7cb7896c825731e7683f5c64dcf8f52fd-
Ignore-this: 363bb3b96b701befb5a8ebb47c5949ad
--
unrevert:[TAG pycryptopp-0.5.15
unrevert-zooko@zooko.com**20090705194216
unrevert- Ignore-this: 363bb3b96b701befb5a8ebb47c5949ad

Oh, and hashed inventory thinks that one of *those* is the next tag that I made
a while later:

HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
grep -B4 -Ee"3ebd0107cf4074b0c6d5a4270c5ee857e95a5071a5a89c1790fde2a8424257c0|
../hashed_inventory-[TAG pycryptopp-0.5.15
../hashed_inventory-zooko@zooko.com**20090705194216
../hashed_inventory- Ignore-this: 363bb3b96b701befb5a8ebb47c5949ad
../hashed_inventory-]
../hashed_inventory:hash:
0000000812-3ebd0107cf4074b0c6d5a4270c5ee857e95a5071a5a89c1790fde2a8424257c0
../hashed_inventory-[TAG pycryptopp-0.5.16
../hashed_inventory-zooko@zooko.com**20090727125049
../hashed_inventory- Ignore-this: be0408712088064c264fe4c8324e8809
../hashed_inventory-]
../hashed_inventory:hash:
0000001125-0b8d2729da1dc3f12ce537cf551ec4d7cb7896c825731e7683f5c64dcf8f52fd

Yep, same thing goes the tags named "pycryptopp-0.5.16":

HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
grep -A2 "pycryptopp-0.5.16" *
0000000388-c3095c23ddc3a799f9ee929149190b57b130414a43d534f3e1b820cef45b5f46:+  
* release pycryptopp-0.5.16
0000000388-c3095c23ddc3a799f9ee929149190b57b130414a43d534f3e1b820cef45b5f46-+
0000000388-c3095c23ddc3a799f9ee929149190b57b130414a43d534f3e1b820cef45b5f46-+  
* setup.py, misc/: a few improvements to the build/packaging
--
0000001125-0b8d2729da1dc3f12ce537cf551ec4d7cb7896c825731e7683f5c64dcf8f52fd:
0000001125-0b8d2729da1dc3f12ce537cf551ec4d7cb7896c825731e7683f5c64dcf8f52fd-
0000001125-0b8d2729da1dc3f12ce537cf551ec4d7cb7896c825731e7683f5c64dcf8f52fd-
Ignore-this: be0408712088064c264fe4c8324e8809
--
0000001299-a02daa62696338693eaf8e83c0fbed7c7dd3f0c939346356deaca6938900c2bd:
0000001299-a02daa62696338693eaf8e83c0fbed7c7dd3f0c939346356deaca6938900c2bd-
0000001299-a02daa62696338693eaf8e83c0fbed7c7dd3f0c939346356deaca6938900c2bd-
Ignore-this: be0408712088064c264fe4c8324e8809
--
unrevert:[TAG pycryptopp-0.5.16
unrevert-zooko@zooko.com**20090727125049
unrevert- Ignore-this: be0408712088064c264fe4c8324e8809

HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
grep -B4 -Ee"a02daa62696338693eaf8e83c0fbed7c7dd3f0c939346356deaca6938900c2bd|
../hashed_inventory-[TAG pycryptopp-0.5.16
../hashed_inventory-zooko@zooko.com**20090727125049
../hashed_inventory- Ignore-this: be0408712088064c264fe4c8324e8809
../hashed_inventory-]
../hashed_inventory:hash:
0000001125-0b8d2729da1dc3f12ce537cf551ec4d7cb7896c825731e7683f5c64dcf8f52fd
--
../hashed_inventory-[TAG pycryptopp-0.5.17
../hashed_inventory-zooko@zooko.com**20090916031341
../hashed_inventory- Ignore-this: 68baf5231e68b10aa649733cc0603529
../hashed_inventory-]
../hashed_inventory:hash: 0000001299-

HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
grep -A2 "pycryptopp-0.5.17" *
0000000603-ee98ff8d5b2582075318fa446a30bcce6896ad966d432d910821d2f815684228:+  
* release pycryptopp-0.5.17
0000000603-ee98ff8d5b2582075318fa446a30bcce6896ad966d432d910821d2f815684228-+
0000000603-ee98ff8d5b2582075318fa446a30bcce6896ad966d432d910821d2f815684228-+  
* publickey/rsamodule.cpp, publickey/ecdsamodule.cpp, hash/sha256module.cpp,
cipher/aesmodule.cpp: fix a segfault bug when sizeof(size_t) > sizeof(int) (not
exploitable); thanks Nathan Wilcox and Brian Warner. ticket #19 2009-09-15 
Zooko O'Whielacronx  <zooko@zooko.com>
--
0000001299-a02daa62696338693eaf8e83c0fbed7c7dd3f0c939346356deaca6938900c2bd:
0000001299-a02daa62696338693eaf8e83c0fbed7c7dd3f0c939346356deaca6938900c2bd-
0000001299-a02daa62696338693eaf8e83c0fbed7c7dd3f0c939346356deaca6938900c2bd-
Ignore-this: 68baf5231e68b10aa649733cc0603529
--
unrevert:[TAG pycryptopp-0.5.17
unrevert-zooko@zooko.com**20090916031341
unrevert- Ignore-this: 68baf5231e68b10aa649733cc0603529

Oh!  At last a tag that has only one patch associated with it!

Oh, but that's probably because I haven't created any new tags since then. 
Let's see what happens if I create one...

HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
darcs tag bogus-tag-debugging-issue1669
Finished tagging patch 'TAG bogus-tag-debugging-issue1669'
HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
grep -A2 "bogus-tag-" *
HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$

Huh ??

Oh, the newly created patches are gzipped:

HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
zgrep -A2 "bogus-tag-" *
0000003602-b52b4473beb7912e3b574257030c115cc7a5ac2bbe697c0cb36a044c19a18e29:
0000003602-
m**20100113051216
0000003602-b52b4473beb7912e3b574257030c115cc7a5ac2bbe697c0cb36a044c19a18e29:
Ignore-this: 671d334dc954fc71ced129c7584d5482
HACK yukyuk:~/playground/pycryptopp/7zfrombug1669/pycryptopp/_darcs/patches$
zgrep -Ee"671d334dc954fc71ced129c7584d5482|20100113051216|

Hm, well I seem to be free of the curse.

Now however can I repair this repository?  I really need to fix it so I can
commit a bunch of improvements to pycryptopp, and it is kind of urgent because
we're trying to get Tahoe-LAFS into Ubuntu Lucid 10.04 LTS and the deadline is
next week.

I don't understand if Kowey's advice on repairing a patch that had extra
whitespace is still sufficient in light of all this weirdness with colliding
patches, and also I didn't understand how to effect that change.

A news update and some clarifications.  News: we now have a workaround to
Zooko's problem.  Just repair the one bad patch that happens to be on the very
top of the stack.

Three clarifications, basically saying to disregard some messages.

- Re msg9779: I somehow managed to find that 'ecdsa: disable ECDSA so that
nobody starts to rely on it (the current version works, but isn't ready for
long-term support)' was the 'earliest' patch based on the corrupted repo.  But I
think I know what my mistake was. The repo had both a corrupt patch and a
corrupt pristine (as if the patch were successfully applied).  My mistake was to
do a darcs get and then a darcs unpull.  Because the darcs get copies the
pristine (for performance reasons), I could unapply the offending patch and only
have the error show up later.

- I believe msg9805 can also be safely ignored due to confusion between the file
content hash and the patch id hash -- see http://wiki.darcs.net/Hashes 

- Petr says we can disregard msg9806; just a slight misunderstanding about what
tags are supposed to contain

OK now we're still stuck on the following question: how did this corrupt
patch/pristine come to be?  

Where did this extra blank line after 's2 = verifier.serialize()' come from? 
It's quite clearly created by something other than Darcs because the line is
non-empty, and it's quite likely a human because the blank line consists of some
whitespace/indentation as you might expect through a text editor.

It seems like somewhere out there, there is a repo where this extra line is
perfectly legit...

I doubt we will be able to come up with any extra steps to reproduce this
(unless Zooko has more ideas), so I guess we'll have to mark this presumed-dead :-(