There is a change in behaviour in Mercurial 2.1, according to Mercurial wiki ( http://mercurial.selenic.com/wiki/UpgradeNotes ): - pull now returns 1 when no changes found to match commit/incoming/outgoing/push. This breaks sync for Mercurial-based overlays if no changes found. Reproducible: Always Steps to Reproduce: 0. Install =dev-vcs/mercurial-2.1 1. layman -a rion 2. layman -s rion Actual Results: * Running Mercurial... # ( cd /var/lib/layman/rion && /usr/bin/hg pull -u http://rion-overlay.googlecode.com/hg/ ) pulling from http://rion-overlay.googlecode.com/hg/ searching for changes no changes found * Failure result returned from Mercurial * * Errors: * ------ * Failed to sync overlay "rion". * Error was: Syncing overlay "rion" returned status 1! * db.sync() Expected Results: Successfull sync, although no changes has been found
hmm... from an email about the old behavior... [Quote] Currently we have the following return codes if nothing is found: commit incoming outgoing pull push intended 1 1 1 1 1 documented 1 1 1 0 1 actual[1] 1 1 1 0 0 The behavior of push is especially surprising as the code sure reads like it ought to work. The use of non-zero return codes for "nothing found" appears in a bunch of places in Mercurial. This traces its origins to the standard behavior of Unix grep which returns 1, thus making a whole bunch of scripty things possible that would otherwise be quite tedious. It was always the intent that you could do: hg pull && do-buildy-things [/Quote] So, I suppose layman will need to ignore the return code, since it is useless to know if there was any real problem running it. Short of parsing it's output to look for "no changes found". That is something I do not want to do. Messages like that are too easily changed between versions and translations. So, end result will be getting bugs submitted for when a mercurial action does fail and layman does not report it as such. I suppose I'll need to put a disclaimer message in place of the success result. :/
I had the same problem (for my overlay on googlecode), but for some reason adding: [alias] pull = pull --insecure to the hgrc of the repository, helped.
(In reply to comment #2) > I had the same problem (for my overlay on googlecode), but for some reason > adding: > > [alias] > pull = pull --insecure > > to the hgrc of the repository, helped. Sorry for the confusion. I played a bit around and it seems alias and some extension (like rebase) change the return value.
Confirmed, using paludis. But the problem is not only limited to syncing overlays, updating live-ebuilds also fails. Just noticed this with media-sound/oss-devel::oss-overlay. !!! ERROR in media-sound/oss-devel-9999::oss-overlay: !!! In mercurial_fetch at line 3407 !!! update failed Using paludis, of course. But mercurial_fetch comes from the standard mercurial.eclass, so not really a fault of paludis, when the eclass-function fails.
Fear not, comrades. It will be fixed in 2.1.1: http://selenic.com/repo/hg/rev/a3dcc59054ca Meanwhile patch could be applied to 2.1
Mercurial 2.1.1 is out
(In reply to comment #6) > Mercurial 2.1.1 is out ...and in Portage tree. Isn't the issue fixed now?
Closing finally. This was due to mercurial upsteam changes which have been reverted.
