1422266 – Build libmspack on all arches

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1422266 - Build libmspack on all arches

Summary: Build libmspack on all arches

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	libmspack
Sub Component:
Version:	7.3
Hardware:	All
OS:	Linux
Priority:	medium
Severity:	unspecified
Target Milestone:	rc
Target Release:	7.4
Assignee:	Richard W.M. Jones
QA Contact:	ldu
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	1386854 1405448 1441918
TreeView+	depends on / blocked

Reported:	2017-02-14 22:27 UTC by Yaakov Selkowitz
Modified:	2019-07-15 09:26 UTC (History)
CC List:	15 users (show)
Fixed In Version:	libmspack-0.5-0.5.alpha.el7
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Clones:	1441918 (view as bug list)
Environment:
Last Closed:	2017-08-01 19:35:52 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2017:2167	0	normal	SHIPPED_LIVE	libmspack bug fix update	2017-08-01 18:18:05 UTC

Description Yaakov Selkowitz 2017-02-14 22:27:19 UTC

libmspack was added to RHEL 7.2 in bug 1223486 for the benefit of open-vm-tools, which is x86_64-only.  Therefore, the package was approved for x86_64 only.  Unfortunately, this was enforced through ExclusiveArch instead of at the RCM level as it should have been[1].

Per bug 1298059, evolution-ews can also benefit from libmspack since 7.3, and is not arch-specific.  Furthermore, Platform Enablement is aiming for complete feature parity on all arches where technically feasible.  Therefore, we are requesting that:

1) PM re-approves libmspack for all arches;
2) libmspack be bumped and rebuilt without ExclusiveArch.

Scratch build on all arches:

https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=12544666

[1] https://mojo.redhat.com/docs/DOC-1091437

Comment 1 Richard W.M. Jones 2017-02-15 13:24:06 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.

Comment 2 Josh Boyer 2017-03-15 23:24:41 UTC

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.

Comment 3 Richard W.M. Jones 2017-03-16 09:13:43 UTC

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.

Comment 4 Richard W.M. Jones 2017-03-16 09:48:46 UTC

Just checked and (1) There is an ExclusiveArch in the package, but
that can be easily removed.  (2) No QA ACK!

Comment 6 Richard W.M. Jones 2017-03-17 09:25:53 UTC

To rel-eng, please waive:

https://errata.devel.redhat.com/rpmdiff/show/169299?result_id=4593856

Comment 7 Milan Crha 2017-03-17 11:50:45 UTC

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?

Comment 8 Richard W.M. Jones 2017-03-17 12:10:07 UTC

$ 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

Comment 9 Jon Disnard 2017-03-17 15:18:04 UTC

(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 :-)

Comment 10 Richard W.M. Jones 2017-03-17 15:26:19 UTC

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.

Comment 11 Milan Crha 2017-03-20 09:32:52 UTC

(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.

Comment 12 ldu 2017-03-29 02:12:10 UTC

(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?

Comment 13 Yaakov Selkowitz 2017-03-29 08:14:51 UTC

(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?

Comment 14 ldu 2017-03-29 10:32:55 UTC

> 
> 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.

Comment 15 Yaakov Selkowitz 2017-03-29 15:24:30 UTC

(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.

Comment 20 ldu 2017-06-07 01:49:47 UTC

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.

Comment 21 errata-xmlrpc 2017-08-01 19:35:52 UTC

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

Note You need to log in before you can comment on or make changes to this bug.