[pacman-dev] [PATCH] fix for incorrect checking of return code, which causes syntax errors
--- scripts/makepkg.sh.in | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index e8aaa8b..9741879 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -693,10 +693,10 @@ extract_sources() { local ret=0 msg2 "$(gettext "Extracting %s with %s")" "$file" "$cmd" if [[ $cmd = bsdtar ]]; then - $cmd -xf "$file" || ret=? + $cmd -xf "$file" || ret=$? else rm -f "${file%.*}" - $cmd -dcf "$file" > "${file%.*}" || ret=? + $cmd -dcf "$file" > "${file%.*}" || ret=$? fi if (( ret )); then error "$(gettext "Failed to extract %s")" "$file" -- 1.7.1
On 16/05/10 05:06, Dieter Plaetinck wrote:
--- scripts/makepkg.sh.in | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index e8aaa8b..9741879 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -693,10 +693,10 @@ extract_sources() { local ret=0 msg2 "$(gettext "Extracting %s with %s")" "$file" "$cmd" if [[ $cmd = bsdtar ]]; then - $cmd -xf "$file" || ret=? + $cmd -xf "$file" || ret=$? else rm -f "${file%.*}" - $cmd -dcf "$file"> "${file%.*}" || ret=? + $cmd -dcf "$file"> "${file%.*}" || ret=$? fi if (( ret )); then error "$(gettext "Failed to extract %s")" "$file"
Good catch. Pushed to my working branch. You should commit patches with "-s" so that you get the signoff line. Allan
On Sun, 16 May 2010 10:13:46 +1000 Allan McRae <allan@archlinux.org> wrote:
You should commit patches with "-s" so that you get the signoff line.
aye! but i wonder what the relevancy of the signoff is. does it just mean "i tested it and approve this change" ? that sort of is already implicit since i submitted the patch, so the signoff just makes it explicit? this would mean i have to commit -s in nearly all git commits i do in my all projects. Dieter
On 16/05/10 21:07, Dieter Plaetinck wrote:
On Sun, 16 May 2010 10:13:46 +1000 Allan McRae<allan@archlinux.org> wrote:
You should commit patches with "-s" so that you get the signoff line.
aye! but i wonder what the relevancy of the signoff is. does it just mean "i tested it and approve this change" ? that sort of is already implicit since i submitted the patch, so the signoff just makes it explicit? this would mean i have to commit -s in nearly all git commits i do in my all projects.
Ask Dan... I assume he wrote the patch submitting guilelines: http://www.archlinux.org/pacman/submitting-patches.html Allan
On Sun, May 16, 2010 at 1:16 PM, Allan McRae <allan@archlinux.org> wrote:
On 16/05/10 21:07, Dieter Plaetinck wrote:
On Sun, 16 May 2010 10:13:46 +1000 Allan McRae<allan@archlinux.org> wrote:
You should commit patches with "-s" so that you get the signoff line.
aye! but i wonder what the relevancy of the signoff is. does it just mean "i tested it and approve this change" ? that sort of is already implicit since i submitted the patch, so the signoff just makes it explicit? this would mean i have to commit -s in nearly all git commits i do in my all projects.
Ask Dan... I assume he wrote the patch submitting guilelines: http://www.archlinux.org/pacman/submitting-patches.html
Allan
From http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Do... 12) Sign your work To improve tracking of who did what, especially with patches that can percolate to their final resting place in the kernel through several layers of maintainers, we've introduced a "sign-off" procedure on patches that are being emailed around. The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as a open-source patch. The rules are pretty simple: if you can certify the below: Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. then you just add a line saying Signed-off-by: Random J Developer <random@developer.example.org> using your real name (sorry, no pseudonyms or anonymous contributions.) Some people also put extra tags at the end. They'll just be ignored for now, but you can do this to mark internal company procedures or just point out some special detail about the sign-off. If you are a subsystem or branch maintainer, sometimes you need to slightly modify patches you receive in order to merge them, because the code is not exactly the same in your tree and the submitters'. If you stick strictly to rule (c), you should ask the submitter to rediff, but this is a totally counter-productive waste of time and energy. Rule (b) allows you to adjust the code, but then it is very impolite to change one submitter's code and make him endorse your bugs. To solve this problem, it is recommended that you add a line between the last Signed-off-by header and yours, indicating the nature of your changes. While there is nothing mandatory about this, it seems like prepending the description with your mail and/or name, all enclosed in square brackets, is noticeable enough to make it obvious that you are responsible for last-minute changes. Example : Signed-off-by: Random J Developer <random@developer.example.org> [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h] Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org> This practise is particularly helpful if you maintain a stable branch and want at the same time to credit the author, track changes, merge the fix, and protect the submitter from complaints. Note that under no circumstances can you change the author's identity (the From header), as it is the one which appears in the changelog. Special note to back-porters: It seems to be a common and useful practise to insert an indication of the origin of a patch at the top of the commit message (just after the subject line) to facilitate tracking. For instance, here's what we see in 2.6-stable : Date: Tue May 13 19:10:30 2008 +0000 SCSI: libiscsi regression in 2.6.25: fix nop timer handling commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream And here's what appears in 2.4 : Date: Tue May 13 22:12:27 2008 +0200 wireless, airo: waitbusy() won't delay [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a] Whatever the format, this information provides a valuable help to people tracking your trees, and to people trying to trouble-shoot bugs in your tree.
participants (3)
-
Allan McRae
-
Dieter Plaetinck
-
Xavier Chantry