Bug 9551 - Resolve string formatting issues in unzip
Summary: Resolve string formatting issues in unzip
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 2.2
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 2.2 M4
Assignee: Plauchu Edwin
QA Contact: Francisco Pedraza
URL:
Whiteboard:
: 10140 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-04-28 12:19 UTC by Joshua Lock
Modified: 2016-09-09 15:48 UTC (History)
10 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Lock 2016-04-28 12:19:14 UTC 
unzip fails to compile with compiler flags which elevate common string formatting issues into an error (-Wformat -Wformat-security -Werror=format-security).
Comment 1 Leonardo Sandoval Gonzalez 2016-05-26 16:39:01 UTC 
Edwin, please check the status of this bug and resolve it if possible.
Comment 4 Jussi Kukkonen 2016-08-16 08:04:36 UTC 
This seems to have broken unzip output formatting (see bug 10140 ).
Comment 5 Leonardo Sandoval Gonzalez 2016-08-16 13:48:23 UTC 
(In reply to comment #4)
> This seems to have broken unzip output formatting (see bug 10140 ).

Thanks for the info.
Comment 6 Benjamin Esquivel 2016-08-18 15:11:42 UTC 
*** Bug 10140 has been marked as a duplicate of this bug. ***
Comment 7 Benjamin Esquivel 2016-08-18 15:12:31 UTC 
bug 10140 was closed but has to be fixed here.
Comment 8 Benjamin Esquivel 2016-08-18 15:14:01 UTC 
setting priority the same as bug 10140
Comment 9 Jussi Kukkonen 2016-08-26 07:32:35 UTC 
If the real fix turns out to be more complex (and I think it will), maybe we should revert 763a3d424 in the mean time?
Comment 10 Aníbal Limón 2016-08-26 15:22:33 UTC 
(In reply to comment #9)
> If the real fix turns out to be more complex (and I think it will), maybe we
> should revert 763a3d424 in the mean time?

I agree, i sent a patch to the ML to revert the Edwin's commit while he made the right fix.

http://lists.openembedded.org/pipermail/openembedded-core/2016-August/125769.html
Comment 11 Plauchu Edwin 2016-08-30 02:38:37 UTC 
This patch solves the strange output
without any need of revert my prior patch
[PATCH V1] at http://lists.openembedded.org/pipermail/openembedded-core/2016-August/125886.html
Comment 12 Leonardo Sandoval Gonzalez 2016-08-30 14:23:47 UTC 
(In reply to comment #11)
> This patch solves the strange output
> without any need of revert my prior patch
> [PATCH V1] at
> http://lists.openembedded.org/pipermail/openembedded-core/2016-August/125886.
> html

Great Edwin. Just one comment: There is no need to include V1 on shortlog. It is implied  if version is not included.