On 2014-07-07 21:13, Niels de Vos wrote: > On Mon, Jul 07, 2014 at 07:29:15PM +0200, Anders Blomdell wrote: >> On 2014-07-07 18:17, Niels de Vos wrote: >>> On Mon, Jul 07, 2014 at 04:48:18PM +0200, Anders Blomdell wrote: >>>> On 2014-07-07 15:08, Lalatendu Mohanty wrote: >>>>>> # rpm -U ./glusterfs-server-3.5qa2-0.722.git2c5eb5c.fc20.x86_64.rpm ./glusterfs-fuse-3.5qa2-0.722.git2c5eb5c.fc20.x86_64.rpm ./glusterfs-cli-3.5qa2-0.722.git2c5eb5c.fc20.x86_64.rpm ./glusterfs-libs-3.5qa2-0.722.git2c5eb5c.fc20.x86_64.rpm ./glusterfs-3.5qa2-0.722.git2c5eb5c.fc20.x86_64.rpm ./glusterfs-api-3.5qa2-0.722.git2c5eb5c.fc20.x86_64.rpm >>>>>> error: Failed dependencies: >>>>>> libgfapi.so.0()(64bit) is needed by (installed) qemu-common-2:1.6.2-6.fc20.x86_64 >>>>>> libgfapi.so.0()(64bit) is needed by (installed) qemu-system-x86-2:1.6.2-6.fc20.x86_64 >>>>>> libgfapi.so.0()(64bit) is needed by (installed) qemu-img-2:1.6.2-6.fc20.x86_64 >>>>>> >>>>>> >>>>>> Feature or bug? >>>>>> >>>>>> /Anders >>>>>> >>>>> Hey Anders, >>>>> >>>>> You should not see this issue as glusterfs-api provides "/usr/lib64/libgfapi.so.0" . >>>>> >>>>> $rpm -ql glusterfs-api >>>>> /usr/lib/python2.7/site-packages/gluster/__init__.py >>>>> /usr/lib/python2.7/site-packages/gluster/__init__.pyc >>>>> /usr/lib/python2.7/site-packages/gluster/__init__.pyo >>>>> /usr/lib/python2.7/site-packages/gluster/gfapi.py >>>>> /usr/lib/python2.7/site-packages/gluster/gfapi.pyc >>>>> /usr/lib/python2.7/site-packages/gluster/gfapi.pyo >>>>> /usr/lib/python2.7/site-packages/glusterfs_api-3.5.0-py2.7.egg-info >>>>> /usr/lib64/glusterfs/3.5.0/xlator/mount/api.so >>>>> /usr/lib64/libgfapi.so.0 >>>>> /usr/lib64/libgfapi.so.0.0.0 >>>> True for branch release-3.5 from git://git.gluster.org/glusterfs.git, but not for master. >>> >>> Indeed, the master branch uses SONAME-versioning. Any applications (like >>> qemu) using libgfapi.so need to get re-compiled to use the update. >> Can do without these for my current testing :-) > > Of course, removing packages you don't need is a nice workaround :) > >> >>> >>>>> >>>>> Is there any specific reason you want to use >>>>> "glusterfs-server-3.5qa2-0.722.git2c5eb5c.fc20.x86_64.rpm"? because >>>>> 3.5.1 is available in fedora 20 in update repo . So if you do yum >>>>> update it i.e. "yum update glusterfs-server" you should get glusterfs >>>>> 3.5.1 GA version which like to be stable than >>>>> glusterfs-server-3.5qa2-0.722. >>>> I would like to track progress of the fixing of my bugs and at the same time experiment >>>> with reverting 3dc56cbd16b1074d7ca1a4fe4c5bf44400eb63ff to re-add IPv6 >>>> support, and I figured that the master is what will eventually become >>>> 3.6.0 >>> >>> Yes, you are correct. The master branch will become glusterfs-3.6. You >>> should be able to recompile qemu (and other?) packages on a system that >>> has glusterfs-devel-3.6 installed. I can also recommend the use of >>> 'mockchain' (from the 'mock' package) for rebuilding glusterfs and other >>> dependent packages. >> I'll keep tracking master (exposing as many bugs as I can), I'll redirect >> followups to gluster-devel@xxxxxxxxxxx and drop gluster-users@xxxxxxxxxxx >> after this message. > > Great, thanks for the testing! Will hopefully get me a better product in the end :-) A few questions: 1. Should bugs/patches be posted on the list or should I file a BugZilla for each? 2. What are the rules for marking a bug as blocking the trackers (can't find one for 3.6.0 yet, so currently a moot point). 3. Given that my understanding of gluster innards is very limited, my guess is that the 'GlusterFS Development Workflow' is a overkill, but please correct me if I'm wrong. /Anders -- Anders Blomdell Email: anders.blomdell@xxxxxxxxxxxxxx Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
