Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Did a bunch of Hackage cabal file revisions just get lost? #305

Closed
snoyberg opened this issue Jan 5, 2015 · 9 comments
Closed

Did a bunch of Hackage cabal file revisions just get lost? #305

snoyberg opened this issue Jan 5, 2015 · 9 comments

Comments

@snoyberg
Copy link
Contributor

snoyberg commented Jan 5, 2015

I went to run my Stackage Nightly build as usual, and suddenly I saw a huge number of restrictive upper bounds (see: commercialhaskell/stackage#394). None of these existed when I ran the check script last, which was approximately 12 hours ago.

Is it possible that there was a problem on Hackage Server, which wiped out all edited Cabal files?
@snoyberg
Copy link
Contributor Author

snoyberg commented Jan 5, 2015

Have a look at the revision dates on this page:

http://hackage.haskell.org/package/imagesize-conduit-1.0.0.4/revisions/

Revision 1 occurred before revision 0, which seems to be the source of this problem. IMO, this is a major bug that needs to be addressed ASAP, it can affect a large number of users very quickly.

@hvr
Copy link
Member

hvr commented Jan 5, 2015

there was a hackage-server update deployment yesterday which seems to have broken the logic

@mietek mietek mentioned this issue Jan 5, 2015
Closed
@hvr hvr mentioned this issue Jan 5, 2015
Closed
hvr referenced this issue Jan 5, 2015
@dcoutts
Re-arrange the PkgInfo representation to make it clearer
e72967a 
And add a number of new helper functions.
And remove some old acid state transactions.
@hvr hvr mentioned this issue Jan 5, 2015
Closed
@snoyberg snoyberg mentioned this issue Jan 5, 2015
Merged
@dcoutts
Copy link
Contributor

dcoutts commented Jan 5, 2015

Doh. Fixing...

dcoutts added a commit that referenced this issue Jan 5, 2015
@dcoutts
Fix a mistaken migration that reversed all .cabal file revisions
e731ec7 
A recent patch changed the representation of the package info, including
the sequence of revisions to the .cabal file. The intention of this
change was to simplify the representation and make it less confusing.
Sadly the confusion bit me in the migration, and I accidentally reversed
all the .cabal file revisions.

This patch adds a follow-up migration that puts them all back in order.

Fixes issue #305.
@dcoutts
Copy link
Contributor

dcoutts commented Jan 5, 2015

Ok, please check now.

@dcoutts
Copy link
Contributor

dcoutts commented Jan 5, 2015

Ironically the original change was to make the representation less confusing, and in the process of migrating from the old representation I got bitten by the confusing representation and managed to reverse all the revisions. Sigh. Sorry folks.

@snoyberg
Copy link
Contributor Author

snoyberg commented Jan 5, 2015

Seems to be working now. I'll kick off a Stackage Nightly build momentarily.

@snoyberg
Copy link
Contributor Author

snoyberg commented Jan 5, 2015

I'm satisfied that the problem is now solved, if you'd like me to close this issue, no problem. Leaving it open for now in case you want to check in with others first.

@dcoutts
Copy link
Contributor

dcoutts commented Jan 5, 2015

and @hvr tells me he's satisfied too so we can close it.

@dcoutts dcoutts closed this as completed Jan 5, 2015
@dcoutts
Copy link
Contributor

dcoutts commented Jan 5, 2015

While obviously this was a cockup on my part, one positive thing arising is that we now have clear evidence that the ability to edit the .cabal files after releases is very useful. When we accidentally reverted to the original revision lots of things broke, so clearly a lot of cases are relying on this feature.

@mietek mietek mentioned this issue Feb 14, 2015
Closed
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@snoyberg @hvr @dcoutts