I might add that I just uploaded gperiodic, and that worked...

I think that this can happen when the script for handling the package build somehow chokes on your package build. You end up with an unzipped package, and either no db entry or a db entry that can't produce a package details page.

I'll snoop around and see if I can figure out the root cause of it. At least there should be some better error handling of this.

Hmmm, the unzipping is going to inevitably lead to a very messy directory full of packages, most of them real and useable, but some failed and derelict. The crudest form of error checking that I can think of right off the bat would be to check for a DB entry -> if not entry, then delete the unzipped data and throw a a generic error.

Along those same lines, it wouldn't kill us to write a simple cleanup script that lists everything in the package directory, and checks for corresponding db entries, if there isn't an entry, maybe move the package to another directory for a manual double check or just plain delete it.

Yes, this definitely needs to be handled better in the short term. I'll work on this ASAP.

Not sure if it'll help but I eliminated the possibility of a rotten PKGBUILD causing this one. I tried again using the skeleton from /var/abs/PKGBUILD.proto, with just the pkgname and pkgver values changed, and it still did the same thing.

I *think* I have got part of this, but maybe not the whole thing. Did the package not appear in the lists *or* enable you to get detail? I just discovered a bug (that I thought had been fixed) that creates problems seeing the detail on a package unless you assigned it a category on upload.

I'm working on the second half of the bug now. Think I'm onto something.

Okay. I've fixed this in svn rev 151. It was the fact that there was a dummy package in the DB before (because of a dependency) and when the real pkg was uploaded, the entry for libticables didn't get its DummyPkg bit set to 0. So the interface ignored the uploaded package as a dummy.

When in fact, we were the dummies. ;)

This fix will go out with v1.0.1.

As part of fixing the first half of this bug, on the v1.0.1 rollout, I should also do a:

UPDATE Packages SET CategoryID = 1 WHERE CategoryID = 19

Well 1> I know I assigned it a category, so that shouldn't be the case this time
2>I can see the package page, and I see that you've been there already
3>Would you mind manually unsetting that dummy bit?
We might want to unset our own as well :)

Since you asked so nicely.. done. Along with the other 9 packages with this problem.