FS#28248 - Mercurial 2.1 Might Return With Non-Zero Exit Codes After Pulling And Break The Build Process
Attached to Project:
Pacman
Opened by Bastien Dejean (baskerville) - Saturday, 04 February 2012, 16:15 GMT
Last edited by Dan McGee (toofishes) - Saturday, 11 February 2012, 21:53 GMT
Opened by Bastien Dejean (baskerville) - Saturday, 04 February 2012, 16:15 GMT
Last edited by Dan McGee (toofishes) - Saturday, 11 February 2012, 21:53 GMT
|
Details
The current version of mercurial returns with non-zero exit
codes on numerous occasions. This behavior is intended
[1].
For example, the following command will return with an exit code of 1 if there's nothing to pull: hg pull When it happens, the build process fails since the makepkg script traps non-zero exit codes: trap 'trap_exit "$(gettext "An unknown error has occurred. Exiting...")"' ERR A patch suggested[2] on the Main Arch Linux Mailing List is attached. [1] http://selenic.com/hg/rev/093b75c7b44b [2] http://mailman.archlinux.org/pipermail/arch-general/2012-February/024835.html |
This task depends upon
Closed by Dan McGee (toofishes)
Saturday, 11 February 2012, 21:53 GMT
Reason for closing: Fixed
Additional comments about closing: commit 9b1ab3d76713d99
Saturday, 11 February 2012, 21:53 GMT
Reason for closing: Fixed
Additional comments about closing: commit 9b1ab3d76713d99
> Returns 0 on success, 1 if there are unresolved files.
(man hg, description of update)
Yes you're right, I went too far.
@engored:
Maybe capturing "hg pull"'s stderr might tell if something really went wrong?
Yes, it seems cleaner.
@stefanhusmann:
You also have to take care of the problem in the PKGBUILD itself...
Anyway, I can also confirm this works when combined with modification of the PKGBUILD.
Thanks guys!
- Returns 0 on success, 1 if an update had unresolved files.
+ Returns 0 on success, 1 if no changes found or an update had
+ unresolved files.
It seems there is no straightforward way to distinguish genuine failure for lack of changes.
An user said that his problem was resolved simply downgrading mercurial to version 2.0.2, so i wonder if at this moment we are looking in the wrong direction for fix this issue.
Because at that point would be a mistake due to the mercurial package and nothing else.
I have this issue on the 64 bit system and don't on the 32 bit system where i tried few day before, but i haven't checked, at that time, which version of mercurial was present on the 32 bit system.
For the moment i haven't tried the solution proposal from that user because i never downgrade a package so i should understand how proceed ( https://wiki.archlinux.org/index.php/Downgrade_packages ) and since at that moment I have no compelling need to use that package if possible i prefer a clean fix.
On summary i hope that the problem resides in the package mercurial.
Yes I think this commit should be reverted.
Would it be conceivable to provide a patched mercurial package?
Alas, some AUR maintainers have already started to change their PKGBUILD (they removed the underscore in the hg variables and append the 'test $? ...' to the 'hg pull' lines) and the irony is: it breaks the build process with mercurial 2.0.2!
I fixed my problem with the downgrade of mercurial suggested from one user.
This leaves me lean even more than before that this is a bug in the program and that the above solutions proposed (a modification of the makepkg and PKGBUILD on program that use mercurial) are a workaround to that problem but the solution lies in fixing bugs in the program mercurial.
If you go in that direction, maybe you could remove the automatic actions performed when _foorepo and _fooroot are defined: I find counterintuitive the fact that a PKGBUILD with an empty 'build' function doesn't do nothing?
If hg pull is called without -u it will only return 1 if there are no file changes, if hg pull fails it returns 255. Only hg pull -u also returns 1 if the update fails.
Basically, run "hg pull" and check the return status:
0 - run "hg update"
1 - do nothing
all others - error exit.
http://selenic.com/hg/rev/a3dcc59054ca
so 'pull' will again return 0.