On 2014-10-30 22:44, Anders Blomdell wrote: > On 2014-10-30 22:06, Kaleb KEITHLEY wrote: >> On 10/30/2014 04:34 PM, Anders Blomdell wrote: >>> On 2014-10-30 20:55, Kaleb KEITHLEY wrote: >>>> On 10/30/2014 01:50 PM, Anders Blomdell wrote: >>>>> On 2014-10-30 14:52, Kaleb KEITHLEY wrote: >>>>>> On 10/30/2014 04:36 AM, Anders Blomdell wrote: >>>>>>> >>>>>>> I think a compat package would make the coupling between server >>>>>>> and client looser, (i.e. one could run old clients on the same >>>>>>> machine as a new server). >>>>>>> >>>>>>> Due to limited time and dependency on qemu on some of my >>>>>>> testing machines, I still have not been able to test >>>>>>> 3.6.0beta3. A -compat package would have helped me a lot (but >>>>>>> maybe given you more bugs to fix :-)). >>>>>> >>>>>> Hi, >>>>>> >>>>>> Here's an experimental respin of 3.6.0beta3 with a -compat RPM. >>>>>> >>>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=7981431 >>>>>> >>>>>> Please let us know how it works. The 3.6 release is coming very >>>>>> soon and if this works we'd like to include it in our Fedora and >>>>>> EPEL packages. >>>>> Nope, does not work, since the running usr/lib/rpm/find-provides >>>>> (or /usr/lib/rpm/redhat/find-provides) on the symlink does not >>>>> yield the proper provides [which for my system should be >>>>> "libgfapi.so.0()(64bit)"]. So no cigar :-( >>>> >>>> Hi, >>>> >>>> 1) I erred on the symlink in the -compat RPM. It should have been >>>> /usr/lib64/libgfapi.so.0 -> libgfapi.so.7(.0.0). >>> Noticed that, not the main problem though :-) >>> >>>> 2) find-provides is just a wrapper that greps the SO_NAME from the >>>> shared lib. And if you pass symlinks such as >>>> /usr/lib64/libgfapi.so.7 or /usr/lib64/libgfapi.so.0 to it, they both >>>> return the same result, i.e. the null string. The DSO run-time does >>>> not check that the SO_NAME matches. >>> >>> No, but yum checks for "libgfapi.so.0()(64bit) / libgfapi.so.0", so >>> i think something like this is needed for yum to cope with upgrades. >>> >>> %ifarch x86_64 >>> Provides: libgfapi.so.0()(64bit) >>> %else >>> Provides: libgfapi.so.0 >>> %endif >> >> >> That's already in the glusterfs-api-compat RPM that I sent you. The 64-bit part anyway. Yes, a complete fix would include the 32-bit too. > A looked/tried at the wrong RPM > >> >>> >>> >>>> I have a revised set of rpms with a correct symlink available >>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=7984220. The main >>>> test (that I'm interested in) is whether qemu built against 3.5.x >>>> works with it or not. >>> First thing is to get a yum upgrade to succeed. >> >> What was the error? > Me :-( (putting files in the wrong location) > > Unfortunately hard to test, my libvirtd (1.1.3.6) seems to lack gluster support > (even though qemu is linked against libvirtd), any recommended version of libvirtd to > compile? With (srpms from fc21) libvirt-client-1.2.9-3.fc20.x86_64 libvirt-daemon-1.2.9-3.fc20.x86_64 libvirt-daemon-driver-interface-1.2.9-3.fc20.x86_64 libvirt-daemon-driver-network-1.2.9-3.fc20.x86_64 libvirt-daemon-driver-nodedev-1.2.9-3.fc20.x86_64 libvirt-daemon-driver-nwfilter-1.2.9-3.fc20.x86_64 libvirt-daemon-driver-qemu-1.2.9-3.fc20.x86_64 libvirt-daemon-driver-secret-1.2.9-3.fc20.x86_64 libvirt-daemon-driver-storage-1.2.9-3.fc20.x86_64 libvirt-daemon-kvm-1.2.9-3.fc20.x86_64 libvirt-daemon-qemu-1.2.9-3.fc20.x86_64 libvirt-devel-1.2.9-3.fc20.x86_64 libvirt-docs-1.2.9-3.fc20.x86_64 libvirt-gconfig-0.1.7-2.fc20.x86_64 libvirt-glib-0.1.7-2.fc20.x86_64 libvirt-gobject-0.1.7-2.fc20.x86_64 libvirt-python-1.2.7-2.fc20.x86_64 I can create a gluster pool, but when trying to create an image I get the error "Libvirt version does not support storage cloning". Will continue tomorrow. Qemu's that does not touch gluster works OK, so the installation is OK right now :-) > >>>>> Have you checked my more heavyhanded http://review.gluster.org/9014 >>>>> ? >>>> >>>> I have. A) it's, well, heavy handed ;-) mainly due to, >>>> B) there's lot of duplicated code for no real purpose, and >>> Agreed, quick fix to avoid soname hell (and me being unsure of >>> what problems __THROW could give rise to). >> >> In C, that's a no-op. In C++, it tells the compiler that the function does not throw exceptions and can optimize accordingly. > OK, no problems there then. > >> >>> >>>> C) for whatever reason it's not making it through our smoke and >>>> regression tests (although I can't imagine how a new and otherwise >>>> unused library would break those.) >>> Me neither, but I'm good at getting smoke :-) >>> >>>> If it comes to it, I personally would rather take a different route >>>> and use versioned symbols in the library and not bump the SO_NAME. >>>> Because the old APIs are unchanged and all we've done is add new >>>> APIs. >>> I guess we have passed that point since 3.6.0 is out in the wild (RHEL), >>> and no way to bump down the version number. >> >> That's RHS-Gluster, not community gluster. There's been some discussion of not packaging 3.6.0 and releasing and packaging 3.6.1 in short order. We might have a small window of opportunity. (Because there's never time to do it right the first time, but there's always time to do it over. ;-) >> >>> >>> >>>> But we're running out of time for the 3.6 release (which is already >>>> months overdue.) > So is my testing, hope I'm not the bottleneck here :-) > >>>> >>>> I don't know if anyone here looked at doing versioned symbols before >>>> we made the decision to bump the SO_NAME. I've looked at Ulrich >>>> Dreppers >>>> https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf >>>> write-up and it's not very hard. >>> Too late now, though? >> >> Perhaps not. > +2 > > > > /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
