Description of problem: Test prove ./tests/basic/rpm.t fails Version-Release number of selected component (if applicable): Git version: commit 8923c14151d646ab90f05addc9e6c3ed178fee10 Date: Tue May 7 15:27:08 2013 +0530 How reproducible: always Steps to Reproduce: 1. run prove ./tests/basic/rpm.t Actual results: # prove ./tests/basic/rpm.t ./tests/basic/rpm.t .. 3/5 ERROR: Cannot build target x86_64 on arch i686 ./tests/basic/rpm.t .. 4/5 ERROR: Cannot build target x86_64 on arch i686 ./tests/basic/rpm.t .. Failed 2/5 subtests Test Summary Report ------------------- ./tests/basic/rpm.t (Wstat: 0 Tests: 5 Failed: 2) Failed tests: 4-5 Files=1, Tests=5, 128 wallclock secs ( 0.01 usr 0.05 sys + 30.88 cusr 104.73 csys = 135.67 CPU) Result: FAIL Expected results: Result: PASS Additional info: Running the 32 bit version of Fedora 17.
it seems that tests/basic/rpm.t hard-codes x86_64 to pick the build-root for mock. This should be modified to use the output of 'uname -i'.
REVIEW: http://review.gluster.org/8214 (Avoid hard-coded x86_64 arch in tests/basic/rpm.t) posted (#1) for review on master by Jose Castillo (jcastill)
REVIEW: http://review.gluster.org/8214 (Avoid hard-coded x86_64 arch in tests/basic/rpm.t) posted (#2) for review on master by Jose Castillo (jcastill)
REVIEW: http://review.gluster.org/8222 (Fixed typo as suggested by Justin Clift.) posted (#1) for review on master by Jose Castillo (jcastill)
REVIEW: http://review.gluster.org/8214 (Avoid hard-coded x86_64 arch in tests/basic/rpm.t) posted (#3) for review on master by Jose Castillo (jcastill)
COMMIT: http://review.gluster.org/8214 committed in master by Vijay Bellur (vbellur) ------ commit 3df72ddcdb371c441b5535ad802fc59a794e3ac9 Author: Jose Castillo <jcastillo> Date: Tue Jul 1 15:51:07 2014 +0200 Avoid hard-coded x86_64 arch in tests/basic/rpm.t tests/basic/rpm.t hard-codes x86_64 to pick the build-root for mock, causing errors when called from a different architecture. With this patch, we use 'uname -i' to select the right architecture. v2: Fixed typo as suggested by Justin Clift. Change-Id: I07bc2af9317dc315bca460149ea3430071537780 BUG: 962169 Signed-off-by: Jose Castillo <jcastillo> Reviewed-on: http://review.gluster.org/8214 Reviewed-by: Vikhyat Umrao <vumrao> Reviewed-by: Justin Clift <justin> Reviewed-by: Humble Devassy Chirammal <humble.devassy> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Lalatendu Mohanty <lmohanty> Reviewed-by: Vijay Bellur <vbellur>
A beta release for GlusterFS 3.6.0 has been released. Please verify if the release solves this bug report for you. In case the glusterfs-3.6.0beta1 release does not have a resolution for this issue, leave a comment in this bug and move the status to ASSIGNED. If this release fixes the problem for you, leave a note and change the status to VERIFIED. Packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update (possibly an "updates-testing" repository) infrastructure for your distribution. [1] http://supercolony.gluster.org/pipermail/gluster-users/2014-September/018836.html [2] http://supercolony.gluster.org/pipermail/gluster-users/
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.6.1, please reopen this bug report. glusterfs-3.6.1 has been announced [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://supercolony.gluster.org/pipermail/gluster-users/2014-November/019410.html [2] http://supercolony.gluster.org/mailman/listinfo/gluster-users