[Gluster-users] Fwd: Compiling Gluster RPMs for v5.x on Suse SLES15

David Spisla spisla80 at gmail.com
Fri Jan 17 13:54:29 UTC 2020


Hello Kaleb,

thanks for the answer. Of course, there will be no 100% guarantees, but if
you say it is the way you used to build it, it looks good to me.
Additionally I have no errors during build and it is running stable.

Regards
David Spisla

ps I do CC to Gluster Mailing List

Am Fr., 17. Jan. 2020 um 14:42 Uhr schrieb Kaleb Keithley <
kkeithle at redhat.com>:

> I'm not sure what the question is here.
>
> The preferred way to build now is with the unbundled rpcgen and libtirpc
> on the platforms that have them. That includes SLE-15 and SLE-15-SP1.
>
> (I'm not sure if there's still some question about the availability of an
> unbundled rpcgen package for SLE-15 or SLE-15-SP1, but somehow it's
> available for SLE-15 in OBS. I have looked several times and am not able to
> determine which repo it comes from. Nor do I have a SLES-15 box of my own.
> Once upon a time SUSE would give me a free fully unencumbered license but
> not any more.)
>
> On platforms that don't have one or the other or both, use the libc
> bundled rpcgen and rpc. That's the way we used to build it, so it's not
> wrong, per se. If it builds without errors, I believe that's as good as it
> can be. If it works, so much the better.
>
> If you're asking for guarantees—   There aren't any.
>
>
>
>
> On Fri, Jan 17, 2020 at 5:34 AM David Spisla <spisla80 at gmail.com> wrote:
>
>> @Kaleb What do you think about that?
>>
>> Hello Rafi,
>>
>> on our SLES15 Build Servers we are using glibc 2.26 which is without SUN
>> RPC in my opinion. See message in Release Notes (
>> https://sourceware.org/ml/libc-alpha/2017-08/msg00010.html):
>>
>> Sun RPC is deprecated.  The rpcgen program, librpcsvc, and Sun RPC headers
>>   will only be built and installed when the GNU C Library is configured with
>>   --enable-obsolete-rpc.  This allows alternative RPC implementations, such
>>   as TIRPC or rpcsvc-proto, to be used.
>>
>> The author from the notice you linked in the last E-Mail is Thorsten Kukuk. Here is another post from him: https://lists.opensuse.org/opensuse-factory/2017-11/msg00323.html
>>
>> According to his post one should use libtirpc-devel if one need RPC code. We also use libtirpc-devel RPM on our Build Servers. Using rpcsvc-proto-devel is only necessary if one needs
>> code from rpcsvc which is not the case I think. According to the description of libtirpc-devel from $ rpm -qa libtirpc-devel :
>>
>> The Transport Independent RPC library (TI-RPC) is a replacement for the
>> standard SunRPC library in glibc which does not support IPv6 addresses.
>> This implementation allows the support of other transports than UDP and
>> TCP over IPv4.
>> Distribution: SUSE Linux Enterprise 15
>>
>> So it seems be OK, using glibc bundled rpc and kick off the requirement rpcgen. But maybe you have some other informations yet...
>>
>> Regards
>>
>> David Spisla
>>
>>
>> Am Fr., 17. Jan. 2020 um 10:28 Uhr schrieb RAFI KC <rkavunga at redhat.com>:
>>
>>> Hi David,
>>>
>>> I think the rpcgen from the glibc should work fine if if glibc is
>>> installed without the deprecated sunrpc functionality which I believe you
>>> do. It is mentioned here in the readme file for the upstream fedora package
>>> https://github.com/thkukuk/rpcsvc-proto/blob/master/README.
>>>
>>>
>>> I guess you are not using libtirpc and using the sunrpc functionality
>>> from glibc. If so things should work fine. But the best person to comment
>>> on it is Kaleb. It would be better if you can followup on that mail again
>>> with Kaleb. Meantime I will also get more information on this.
>>>
>>>
>>> Rafi KC
>>> On 1/16/20 4:28 PM, David Spisla wrote:
>>>
>>> Hello Rafi,
>>>
>>> below there is a issue I opened on the Gluster Mailing List.
>>> Unfortunately there is no answer :-( .
>>> Do you have an opinion about that?
>>>
>>> My first tests show that the self-compiled RPMs running stable.
>>>
>>> Regards
>>> David Spisla
>>>
>>> ---------- Forwarded message ---------
>>> Von: David Spisla <spisla80 at gmail.com>
>>> Date: Di., 14. Jan. 2020 um 12:03 Uhr
>>> Subject: Compiling Gluster RPMs for v5.x on Suse SLES15
>>> To: gluster-users at gluster.org List <gluster-users at gluster.org>, Gluster
>>> Devel <gluster-devel at gluster.org>, Kaleb S. KEITHLEY <
>>> kkeithle at redhat.com>
>>>
>>>
>>> Dear Gluster Community,
>>>
>>> I want to compile my own Gluster RPMs for v5.x on a Suse Sles15 machine.
>>> I am using the spec file from here:
>>> https://github.com/gluster/glusterfs-suse/blob/sles15-glusterfs-5/glusterfs.spec
>>>
>>> There is a Build Requirement 'rpcgen' which causes confusion to me. I
>>> had a chat with Kaleb Keithley a few months ago:
>>> https://lists.gluster.org/pipermail/gluster-users/2019-May/036518.html
>>>
>>> This statement seems to be interesting:
>>>
>>> „Miuku on #opensuse-buildservice poked around and found that the unbundled
>>>
>>> rpcgen in SLE_15 comes from the rpcsvc-proto rpm. (Not the rpcgen rpm as
>>> it does in Fedora and RHEL8.)
>>>
>>>
>>>
>>> All the gluster community packages for SLE_15 going back to glusterfs-5.0
>>> in October 2018 have used the unbundled rpcgen. You can do the same, or
>>> remove the BuildRequires: rpcgen line and use the glibc bundled rpcgen.“
>>>
>>>
>>> Unfortunately there is no rpcsvc-proto rpm for SLES15:
>>> https://software.opensuse.org/package/rpcsvc-proto?locale=fa
>>>
>>>
>>> I don't know where the guys from Suse OBS had this rpm from. There is
>>> maybe the way to compile the rpcsvc-proto src rpm  on a SLES15, but this is
>>> no good solution in my opinion. So I tried to remove the 'rpcgen'
>>> requirement from the spec file and create the RPMs by using glibc bundled
>>> rpcgen according to Kalebs advise. It works and Gluster seems to be running
>>> stable.
>>>
>>>
>>> Do you think there are any risks in using glibc bundled rpcgen for
>>> creating Gluster 5.x RPMs
>>>
>>> or should I prefer the rpcgen from rpcsvc-proto rpm ?
>>>
>>>
>>> Regards
>>>
>>> David Spisla
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20200117/8443e443/attachment.html>


More information about the Gluster-users mailing list