Autopatch hungs at patches with bad filenames
Closed this issue · 9 comments
Use case:
One accidentaly put autopatch with incorrect filename and trying to resolve -x ebuild which will use this patch.
Result:
Paludis hangs on this line (with quiet = true in output.conf):
*** Applying /usr/portage/local/autopatches/ebuild_unpack_post/app-vim/locateopen/mlocate-support.patch ...
With quiet = false additionaly (but it's no matter):
File to patch: tar jxf /usr/portage/distfiles/locateopen-1.3.tar.bz2 --no-same-owner
We can proceed with pressing enter 2-3 times and die with error.
After this we see:
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
|--- locateopen.vim 2016-01-30 22:41:27.567804708 +0300
|+++ locateopen.vim 2016-02-01 03:11:37.815735679 +0300
File to patch: Skip this patch? [y] Skipping patch.
I.e. patch is waiting for filename but non-interactive cave provides nothing.
Expected behavior:
Error message when file for patching not found.
Dunno that you can fix this because it is patch ignores -s option in case of non-existing files. But maybe you can come up with workaround (eg parsing patch output or setting timeout).
I've found kind of hackish workaround ;-) Actually if there is no epatch declared, we still can inherit it ;-) The main feature of using it is a sane behaviour in case of failure. For example I've broke one of my autopatches (one I usually apply to bash) and got the following output:
>>> Done src_unpack
* Applying bash-4.2-unicode-triple-dot-trim-path.patch ...
workdir-tmpfs> Moving failed build out of RAM: /dev/shm/app-shells-bash-4.3_p42-r2 --> /storage/tmp/paludis/app-shells-bash-4.3_p42-r2
* Failed Patch: bash-4.2-unicode-triple-dot-trim-path.patch !
* ( /var/db/paludis/autopatches/ebuild_unpack_post/app-shells/bash/bash-4.2-unicode-triple-dot-trim-path.patch )
*
* Include in your bugreport the contents of:
*
* /storage/tmp/paludis/app-shells-bash-4.3_p42-r2/temp//bash-4.2-unicode-triple-dot-trim-path.patch.out
!!! ERROR in app-shells/bash-4.3_p42-r2::gentoo:
!!! In epatch at line 2074
!!! Failed Patch: bash-4.2-unicode-triple-dot-trim-path.patch!
!!! Call stack:
!!! * epatch (/storage/tmp/paludis/app-shells-bash-4.3_p42-r2/temp/loadsaveenv:2074)
!!! * try_to_apply_patches (/etc/paludis/hooks/ebuild_unpack_post/auto-patch.bash:42)
!!! * source (/etc/paludis/hooks/ebuild_unpack_post/auto-patch.bash:66)
!!! * perform_hook (/storage/tmp/paludis/app-shells-bash-4.3_p42-r2/temp/loadsaveenv:3535)
!!! * ebuild_main (/usr/libexec/paludis/ebuild.bash:681)
!!! * main (/usr/libexec/paludis/ebuild.bash:691)
Please try the updated master, but if you use a package env files facility, then ... huh, some work needs to be done to port old way conf files... before this fix I've also made a lot of changes into this plugins also...
Awesome! Now cave resolve fails at patching in both cases: wrong filenames, mailformed or incompatible patch file.
And other points.
I can't remember that I used package.env (but maybe it is used silent and automatically).
I found filesystem-manager unsuitable for my case - I have a second layout jist in case, eg for guest logins on my PC. Localepurge does exactly that I need.
To be honest, I am really interested only in autopatch feauture because I'm too lazy for supporting bunch of local ebuilds.
I can't remember that I used package.env (but maybe it is used silent and automatically).
Then relax... ;) nowadays you need to add one line to your /etc/paludis/bashrc explicitly to use it...
Localepurge does exactly that I need.
Filesystem hook do the same, but better in this case :) -- you don't need to execute localepurge (manually or periodically by crond -- I'm too lazy to do this ;) )... cleanup would happened at merge ebuild phase, so on uninstall the package manager wouldn't complain about gone files...
Sorry for long offtopic, but I can't figure how to configure fsmanager to remove all locales except selected (without enumeration of all that need to be cleaned).
For me paludis never complained about gone files, dunno why. And localepurge called by one of the hooks, so not need to execute it manually.
to remove smth except selected items the rm element has reverse attribute (yep, recently I've discovered that name is not good). Setting it to true will to that you need... Docs has a usage example of it. In your case it might be smth like this:
<package spec="*/*" descr="locale-cleaner">
<rm cd="/usr/share/locale/" dst="{en_US,ru_RU}/LC_MESSAGES/*.mo" reverse="true" />
</package>
You may find more usage examples here -- I really like to use this hook to fix/cleanup images of packages going to be installed to my system ... I'm too lazy to fix crappy ebuilds and maintain them in my overlay ;)
Well, maybe you convinced me.
Yeah, "reverse" is not good. In gitignore this is called "negative patterns", but this is not fully clear too, <norm/> is most intuitive but if you want to keep rm syntax when I suggest you to use negative.
The correct fix is to either pass -f directly to patch or make a dry run first via patch --dry-run -f ... and then examine the exit code and do a regular patch.
If you get the patch-level wrong, then that's a user error. Automagically determining the patch-level is a mis-feature, but it should indeed just die without interactivity... hence -f.
Yes, you're right, eutils has same check. I'll try to implement it now.
Thanks.