Summary: | app-portage/layman-2.0.0_rc3 fails sync if no changes in a Mercurial overlay with Mercurial 2.1 | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Denis Lisov <dennis.lissov> |
Component: | Unclassified | Assignee: | Portage Tools Team <tools-portage> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | hsggebhardt, junghans, mobiusstripper, skrattaren |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Denis Lisov
2012-02-04 08:53:18 UTC
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. |