It's this one, but if it's only happening to that project, then I can live with the breakage.
The trouble was triggered by tagging a Mercurial repo via the project's webpage, which I did largely just to see how it would work. Results were... educational! :-) I've deleted the wonky tags and pushed a new tag from my system rather than the webpage, and the packager did all the right things (game client 4.3.4, -nolibs, etc).
Something seems a little odd in how the repo is being tagged via the webpage. I tagged it at revision N, and it produced revision N+1, that's normal. I pulled back down and merged the two, and got revision N+2 locally, that's normal. Its method of tagging was just to write a line into the .hgtags file, which is perfectly normal.
Investigating later, I tried checking out revision N+1 to see exactly what it had worked with. It turns out that
a) there were no other files in that changeset; only .hgtags. Dunno whether that's normal or not.
b) the associated changeset that it had written into .hgtags was the all-0's ID that means "this tag does not exist (deletion, etc)". That doesn't seem normal.
No clue what's up with the 5.0.1 and missing nolibs though.
I'm actually surprised it did anything via webpage-tagging: That's pretty much for Subversion repositories only. Git and Mercurial have rather straightforward ways of tagging/pushing tags via commandline or your DVCS client.
Having .hgtags as the only changeset in a commit is normal for Mercurial.
Makes sense. I was curious to see if the webpage tagging would let me get around the interaction with Mercurial tagging and "package on alpha, beta, and release", where pushing a tag triggers a pair of packaging runs (since the tag generates its own commit).
The answer seems "most definitely not", heh, so I've switched the repo to only package on beta and releases, and going back to tagging via command line (infinitely more convenient than SVN's command line).
Since the thread title is the same, I'm borrowing it. If I'm in the wrong, feel free to split the threads.
I just updated and tested LibResComm-1.0 and SmartRes2 on the MoP beta, and tagged them. After a few normal minutes, they showed up on Curse - in both the recently updated addons for live, and the other downloads on their respective pages. That isn't really a problem, but I'm curious why they didn't show up in the Mists addon section of Curse? Was it the tag names I used?
Go to the Files section of the projects, and you'll see that they're listed as "Game version" 4.3.4 - this means folks using the Curse Client will get those, and if they aren't compatible with the 4.3.4, they'll have broken versions. Setting the ToC Interface to 50001 will correctly package for MoP 5.0.4.