Bug 1422266
| Summary: | Build libmspack on all arches | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Yaakov Selkowitz <yselkowi> | |
| Component: | libmspack | Assignee: | Richard W.M. Jones <rjones> | |
| Status: | CLOSED ERRATA | QA Contact: | ldu <ldu> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 7.3 | CC: | boyang, cavery, germano.massullo, jen, jvavra, jwboyer, ldu, leiwang, mcrha, mtessun, rjones, snagar, virt-bugs, yacao, yselkowi | |
| Target Milestone: | rc | |||
| Target Release: | 7.4 | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | libmspack-0.5-0.5.alpha.el7 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1441918 (view as bug list) | Environment: | ||
| Last Closed: | 2017-08-01 19:35:52 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1386854, 1405448, 1441918 | |||
|
Description
Yaakov Selkowitz
2017-02-14 22:27:19 UTC
Since libmspack is an archive extractor for MSFT formats, it processes files which use little endian fields everywhere. I checked the sources of libmspack and it does appear to take endianness into account, and convert little endian headers into native endian data structures, which is good. I also wanted to find out if the code would compile on aarch64, ppc64 and ppc64le. There is a supplied test suite (upstream) which I could run which has about 20 test files. The results of that: Distro Arch Build Upstream test suite Fedora 25 aarch64 OK* Passed Fedora 25 ppc64 OK* Passed Fedora 25 ppc64le OK* Passed * There are some type-punning warnings and incorrect format string warnings. However these are the same as on x86-64. Given devel_ack+ and pm_ack+ have been set, is there a rebuild of this package planned for 7.4? That would be required to pick up the other architectures. There are no other changes planned for this package, so we wouldn't normally do a rebuild for any other reason. However I can rebuild the package for this bug. Just checked and (1) There is an ExclusiveArch in the package, but that can be easily removed. (2) No QA ACK! To rel-eng, please waive: https://errata.devel.redhat.com/rpmdiff/show/169299?result_id=4593856 Could you mark that libmspack-0.5-0.5.alpha.el7 for a build root, or eventually to the GNOME side tag: $ brew tag-build rhel-7.4-gnome libmspack-0.5-0.5.alpha.el7 thus I can rebuild evolution-ews against it, please? $ brew tag-build rhel-7.4-gnome libmspack-0.5-0.5.alpha.el7 Created task 12794801 Watching tasks (this may be safely interrupted)... 12794801 tagBuild (noarch): open (ppc-030.build.eng.bos.redhat.com) 12794801 tagBuild (noarch): open (ppc-030.build.eng.bos.redhat.com) -> closed 0 free 0 open 1 done 0 failed 12794801 tagBuild (noarch) completed successfully (In reply to Richard W.M. Jones from comment #6) > To rel-eng, please waive: > > https://errata.devel.redhat.com/rpmdiff/show/169299?result_id=4593856 waived :-) Thanks Jon. The erratum (https://errata.devel.redhat.com/advisory/27236) is nagging about lack of a QE owner for this package, although that didn't stop me from changing the state to QE. I don't know who should be QE contact for this package. (In reply to Richard W.M. Jones from comment #8) > 12794801 tagBuild (noarch) completed successfully Thanks, it works fine, thus I'm going to use it in evolution-ews on all arches. (In reply to Richard W.M. Jones from comment #10) > Thanks Jon. The erratum (https://errata.devel.redhat.com/advisory/27236) > is nagging about lack of a QE owner for this package, although that > didn't stop me from changing the state to QE. I don't know who should > be QE contact for this package. @Richard, I can take the QE contact for this package, I used to test libmspack package on RHEL7 x86_64 guest. @yselkowi, now we don't have test ENV to test libmspack on other arches except x86_64,could you help offer the test result on other arches? and could you help to give some description about how to verify libmspack works well? (In reply to ldu from comment #12) > @yselkowi, now we don't have test ENV to test libmspack on other arches > except x86_64,could you help offer the test result on other arches? > and could you help to give some description about how to verify libmspack > works well? I added the following to libmspack.spec: %check pushd test ./cabd_test popd And ran a scratch build: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=12893081 On every arch, the results are identical: + ./cabd_test test_files/cabd/bad_nofolders.cab: no folders in cabinet. test_files/cabd/bad_nofiles.cab: no files in cabinet. ALL 194 TESTS PASSED. I'm not sure how else to test this. How would you verify it on x86_64?
>
> I'm not sure how else to test this. How would you verify it on x86_64?
Thanks very much for you provide the test information.
For x86_64,libmspack installed with open-vm-tools, after open-vm-tools installed, we check the libmspack is also installed, and also check the dependency list of open-vm-tools.
(In reply to ldu from comment #14) > For x86_64,libmspack installed with open-vm-tools, after open-vm-tools > installed, we check the libmspack is also installed, and also check the > dependency list of open-vm-tools. evolution-ews also uses libmspack now: https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=546225 Look for the libmspack.so.0 or libmspack.so.0()(64bit) dependency. verify this bug on RHEL7.4. As this bug metioned libmspack is a dependency of evolution-ews, checked the x86_64, aarch64,ppc64el, package is list in these architectures. as bug 1441918 comments 2 mentioned the libmspack not present on ppc64 and s390x is by design. It is pass with sanity test. The test result: Verified: SanityOnly. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2167 |