Bug 1559181

Ping - does somebody care about this issue? ;-)

Florian, could you alternatively please have a look to? Thanks.

(In reply to Robert Scheck from comment #1)
> Florian, could you alternatively please have a look to? Thanks.

I help to fix this issue upstream; version 1.4 should no longer have this problem.

(In reply to Florian Weimer from comment #2)
> (In reply to Robert Scheck from comment #1)
> > Florian, could you alternatively please have a look to? Thanks.
> 
> I help to fix this issue upstream; version 1.4 should no longer have this
> problem.

How do you generate MT-safe code for libraries (both glibc and
libtirpc) that aren't themselves MT-safe?

The bug has been fixed about 2 months ago.  This was the maintainers response about my help and my reply:

***

Delivered-To: besser82***@***
Received: by 2002:ab0:461a:0:0:0:0:0 with SMTP id m26-v6csp3944108uaa;
        Tue, 29 May 2018 07:27:10 -0700 (PDT)
X-Google-Smtp-Source: ADUXVKLHxvKCH/eNO9LHW5/uXtlxln7mnXd/UczuM577Al4R5XPniUQTFQsBhC61ojGx7ygyUDp0
X-Received: by 2002:a37:7283:: with SMTP id n125-v6mr15147158qkc.78.1527604030219;
        Tue, 29 May 2018 07:27:10 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1527604030; cv=none;
        d=google.com; s=arc-20160816;
        b=cHchvPpdiSy5RQt7j1zx3K+++suuHTYl6/YXVuO6jnwxgUgXKuCX3KGK54MQAKbMed
         2MHgZexJsiw0pLQ+KFXzYj3RZwF9yuanrW4K1o+1Vf/wPnXK9za+mX7A/lSAED/cmD8y
         dIC+xIddBfQ8O77PwNfRZ8vLoV4zJkCdjYDB7uPez8hNS1UhBm+n6ZV4afgB05inP5Sr
         1rj7NJ4IRg4zf02PCD9WI9qbyh9WfIe3Gl6X58WU5FLxzpnzXzUYZQf1DP4F3GMICYOa
         S0qqKS4la2sXNwOgGSdfC6i9LpMKhPB+moM7Jyx1j1xsPPIPZS6mG1wxE3erL7FUNtM7
         /QEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:content-language:mime-version:user-agent
         :date:message-id:cc:subject:from:to:dkim-filter:delivered-to
         :arc-authentication-results;
        bh=53ldkD+j4hvxzjBPZHKOFQKFMQqo0ZAukZmM1axDQ1I=;
        b=srKHI1UwVcBa/WMgUoLFIffFiOpA/Y+neUN/t00b/Z+LK7GH8jr91ffuY3ltN4gmB9
         LJlFnXDzyg5VSyb59IBA+k/SvMuGhi0U1dGuVE33uWrxUiadWfYJBe+p63D70QsraJJS
         l4MYiJNbDuV6eAA3D7KpB06WClccGBZiVSSyZR6BW7EaK7m/zl/3tJW6fFvKDiAtOG1e
         lyopftgSMmXegUiBNckG57RCaV3XWkxsuNlAWckrhHlB8JVxv1utfwklZop+fx9J4M+i
         E7JkBfjLQJ/UJXyUESNQAXJDV+Jy5RNBNC4hfEQQ17Xj1ObD2oTkUheYyREoBC7T0h1A
         aNbQ==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=fail (google.com: domain of steved does not designate 209.132.181.3 as permitted sender) smtp.mailfrom=SteveD;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com
Return-Path: <SteveD>
Received: from bastion.fedoraproject.org (bastion02.fedoraproject.org. [209.132.181.3])
        by mx.google.com with ESMTPS id p22-v6si4915766qtn.124.2018.05.29.07.27.10
        for <besser82.fpo>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 29 May 2018 07:27:10 -0700 (PDT)
Received-SPF: fail (google.com: domain of steved does not designate 209.132.181.3 as permitted sender) client-ip=209.132.181.3;
Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of steved does not designate 209.132.181.3 as permitted sender) smtp.mailfrom=SteveD;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com
Received: by bastion02.phx2.fedoraproject.org (Postfix) id 895A4607EE78; Tue, 29 May 2018 14:27:09 +0000 (UTC)
Delivered-To: besser82
Received: from mx1.redhat.com (ext-mx08.extmail.prod.ext.phx2.redhat.com [10.5.110.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by bastion02.phx2.fedoraproject.org (Postfix) with ESMTPS id 57E1D607EE74 for <besser82>; Tue, 29 May 2018 14:27:09 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 bastion02.phx2.fedoraproject.org 57E1D607EE74
Received: from smtp.corp.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 49681C00C8FD for <besser82>; Tue, 29 May 2018 14:27:09 +0000 (UTC)
Received: from steved.boston.devel.redhat.com (ovpn-116-111.phx2.redhat.com [10.3.116.111]) by smtp.corp.redhat.com (Postfix) with ESMTP id D805D1BBC3; Tue, 29 May 2018 14:27:08 +0000 (UTC)
To: besser82
From: Steve Dickson <SteveD>
Subject: rpcsvc-proto
Cc: Matthew Miller <mattdm>, Stephen Gallagher <sgallagh>
Message-ID: <ef55e8cb-87e2-3924-5846-2946e5a41ebf>
Date: Tue, 29 May 2018 10:27:08 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.27
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 29 May 2018 14:27:09 +0000 (UTC)


> About:
>
> commit 640a0f5f08e61a63a42aa4c3ce1af9078cd90a55 (HEAD -> master, origin/master,
> origin/f28, origin/HEAD)
> Author: Bj?rn Esser <besser82>
> Date:   Tue Mar 27 11:41:01 2018 +0200
>
>     Enable MT code as libtirpc supports it
>
> Please... in the future please either do a pull request or
> send me mail... I've would have rather updated to the
> latest up stream release then do this patch.

I'll do so in future.  At the time I added this patch, there was no newer upstream release and without this patch the gluster-block package was FTBFS. [1]


> How did you test this patch?

Since rpcsvc-proto is perfectly the same code as used in previous versions of glibc.  I investigated how the glibc version was enabling MT-support and concluded, the plain difference is about the macro conditional removed by my patch.  Then I diffed a generated c file with MT-support from the patch version of rpcsvc and the rpcgen built from glibc sources.  There was no meaningful difference between them.

How did you test the package *BEFORE* importing it to make sure it wouldn't introduce this kind of regression?


> Why did you decided to diverge from upstream?

I did NOT diverge from upstream.  Florian Weimer (fweimer) (glibc developer from redhat) submitted it to upstream [2].  My patch pratically was a simple backport from upstream.  Upstream's recently released v1.4 is simply v1.3 + my patch, no further changes. [2]

The second thing to mention here: I added this patch for the rebuilds needed to be done for the json-c 0.13-series update, which included the gluster-block package.


> Why didn't you update the bz that is associated?

For some reason bodhi didn't show me about the report in rhbz when I submitted the update.  :/  Otherwise I would have done so.


> I know you PRs have a wide view of things, but us
> maintainers have a move pointed point of view.
> Let us do our job... Please!

Just to say this directly:  If you would have done your job, you would have seen my unmodified patch merged by upstream on the same day I applied it, would have known the change process owner submitted it upstream and wouldn't have complained about others doing your work, not to mention you are coming up with this complain after 2 months…  About the rhbz ticket:  You didn't even respond there until today tho the ticket is assigned to you, was opened a week *BEFORE* I pushed the patch and at a point, where this should have been a release blocker?  And since you pointed this email to sgallagher and mattdm to obviously threatening me, does your supervisor know about all these facts?


> So in the future please used pull requests
> on any of the packages I maintain. I give
> them top priority and try to knock them
> out as fast as I can.

As I already said, I'll use PRs in future.

FYI, I'll post this reply in the corresponding rhbz ticket for documentation about volunteer community members are being threatened by redhat employees for fixíng the stuff they don't bother to do.

Cheers,
  Björn / besser82

[1]  https://koji.fedoraproject.org/koji/packageinfo?packageID=24885
[2]  https://github.com/thkukuk/rpcsvc-proto/commits/master

For clarification:  The thread is NOT the contents of the email itself, but the direct CC of Stephen and Matt for immediately bringing in the council and FESCo without any prior attempt to get that sorted out in personal conversation.

(In reply to Björn 'besser82' Esser from comment #4)
> The bug has been fixed about 2 months ago.  This was the maintainers
> response about my help and my reply:
> 
> ***
> 
> > About:
> >
> > commit 640a0f5f08e61a63a42aa4c3ce1af9078cd90a55 (HEAD -> master, origin/master,
> > origin/f28, origin/HEAD)
> > Author: Bj?rn Esser <besser82>
> > Date:   Tue Mar 27 11:41:01 2018 +0200
> >
> >     Enable MT code as libtirpc supports it
> >
> > Please... in the future please either do a pull request or
> > send me mail... I've would have rather updated to the
> > latest up stream release then do this patch.
> 
> I'll do so in future.  At the time I added this patch, there was no newer
> upstream release and without this patch the gluster-block package was FTBFS.
> [1]
Thank you!

> 
> 
> > How did you test this patch?
> 
> Since rpcsvc-proto is perfectly the same code as used in previous versions
> of glibc.  I investigated how the glibc version was enabling MT-support and
> concluded, the plain difference is about the macro conditional removed by my
> patch.  Then I diffed a generated c file with MT-support from the patch
> version of rpcsvc and the rpcgen built from glibc sources.  There was no
> meaningful difference between them.
> 
> How did you test the package *BEFORE* importing it to make sure it wouldn't
> introduce this kind of regression?
I had the command generation the needed mountd, statd and export
code then did my usual nfs testing... Basically this patch is
not needed for my world. 

> 
> 
> > Why did you decided to diverge from upstream?
> 
> I did NOT diverge from upstream.  Florian Weimer (fweimer) (glibc developer
> from redhat) submitted it to upstream [2].  My patch pratically was a simple
> backport from upstream.  Upstream's recently released v1.4 is simply v1.3 +
> my patch, no further changes. [2]
Right... so updating to v1.4 would have been my call... 

> 
> The second thing to mention here: I added this patch for the rebuilds needed
> to be done for the json-c 0.13-series update, which included the
> gluster-block package.
Fair enough... 

> 
> 
> > Why didn't you update the bz that is associated?
> 
> For some reason bodhi didn't show me about the report in rhbz when I
> submitted the update.  :/  Otherwise I would have done so.
> 
> 
> > I know you PRs have a wide view of things, but us
> > maintainers have a move pointed point of view.
> > Let us do our job... Please!
> 
> Just to say this directly:  If you would have done your job, you would have
> seen my unmodified patch merged by upstream on the same day I applied it,
> would have known the change process owner submitted it upstream and wouldn't
> have complained about others doing your work, not to mention you are coming
> up with this complain after 2 months…  About the rhbz ticket:  You didn't
This is not a complaint... its a simple request to keep us maintainers in the loop.

Yes, the bz has been open for 2 months, but as you pointed out
the upstream commit happen last Sunday (May 27).

> even respond there until today tho the ticket is assigned to you, was opened
> a week *BEFORE* I pushed the patch and at a point, where this should have
> been a release blocker?  And since you pointed this email to sgallagher and
> mattdm to obviously threatening me, does your supervisor know about all
> these facts?
No... I cc-ed them to keep the conversation civilized... Unfortunately a
number of your colleagues become unhinged with these type of push backs.
Obviously, this is not case here...  

And to document that fact I don't think PRs should be able
to change technology in packages w/out consulting the maintainer. 

> 
> 
> > So in the future please used pull requests
> > on any of the packages I maintain. I give
> > them top priority and try to knock them
> > out as fast as I can.
> 
> As I already said, I'll use PRs in future.
Thank you again!

> 
> FYI, I'll post this reply in the corresponding rhbz ticket for documentation
> about volunteer community members are being threatened by redhat employees
> for fixíng the stuff they don't bother to do.
My apologies if you felt threatened... I was just try to make a point
that changing technology without consulting the maintainer is 
is not a good practice... IMHO... 

steved.

rpcsvc-proto-1.4-0.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-527b8f3a55

rpcsvc-proto-1.4-0.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-527b8f3a55

rpcsvc-proto-1.4-0.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.