Red Hat Bugzilla – Bug 688871
update running_handles counter properly in curl_multi_remove_handle()
Last modified: 2013-07-03 00:12:02 EDT
2. What is the nature and description of the request? The RHEL5 version of curl does not support MULTI properly for uses such as with git-push as detailed here: http://mattiasgeniar.be/2011/03/04/centos-git-http-push-unavailable-git-not-compiled-with-use_curl_multi/ 3. Why does the customer need this? (List the business requirements here) They would like to be able to use functionality in git that is not possible due to curl being too old 4. How would the customer like to achieve this? (List the functional requirements here) They need MULTI support for curl added to enhance interoperability with git 5. For each functional requirement listed in question 4, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Client will successfully be able to use git-push as discussed: http://mattiasgeniar.be/2011/03/04/centos-git-http-push-unavailable-git-not-compiled-with-use_curl_multi/ 6. Is there already an existing RFE upstream or in Red Hat bugzilla? I did not see any relevant/similar BZs for RHEL5 7. How quickly does this need resolved? (desired target release) Preferably the next minor release 8. Does this request meet the RHEL Inclusion criteria (please review) I'm not familiar with the curl codebase but assuming it is a minor update I believe it does. 9. List the affected packages Curl 10. Would the customer be able to assist in testing this functionality if implemented? Yes
When building git, one can set CURLDIR to use an alternative curl version (as documented in its Makefile headers). As we don't ship git... Couldn't customers going with a third-party git use a third-party libcurl? I'm not sure it makes much sense to rebase curl for a component neither Red Hat or any of its partners ships. Based on your link, git _intentionally_ doesn't build if libcurl is "too old": --- *NOTE*: This command is temporarily disabled if your libcurl is older than 7.16, as the combination has been reported not to work and sometimes corrupts repository. --- If we want to fix this, instead of rebasing curl, it could make more sense to: - remove this behaviour in the git build system by reversing the trivial git.git commit 9cf04301b182c4c57d62ea63554d109db613f9d3. - fixing the RHEL5 libcurl by backporting the simple curl.git commit 2ff609dd43cb5c1c0da893c080132a48a2d4c73b Would that solution be acceptable? If so, we can quickly build curl test packages with the backported fix. -- Pierre
Adjusting NEEDINFO to Robert Munilla who owns the customer case behind this feature request. My EUR 0.02: > As we don't ship git... We don't, but do note that git is available in EPEL. > Couldn't customers going with a third-party git use a third-party libcurl? I'm sure they could if there is no alternative. I'm also quite sure they'd prefer for us to address this if possible. That's what this feature request is about, and I believe this is a very reasonable request for a customer to ask us to evaluate. > I'm not sure it makes much sense to rebase curl The request is not to rebase curl; the request is to make this particular functionality available in RHEL5. A rebase would be one way of going about this, but a selective backport (if feasible) would probably fit better with enterprise stability requirements.
I'm not sure I understand the object of the RFE. (In reply to comment #3) > I'm also quite sure they'd prefer for us to address this if possible. > That's what this feature request is about, and I believe this is > a very reasonable request for a customer to ask us to evaluate. (In reply to comment #3) > The request is not to rebase curl; [...] When building git, a feature isn't enabled at compile time if the libcurl version is older than 7.16. We ship 7.15. What "feature" could we expect in our libcurl package to "fix" this without a rebase? Only way I can think of would be to cheat on the libcurl version before rebuilding git... -- Pierre Carrier
I asked the EPEL maintainer (Todd Zullinger) of git about this and he said: > I'd be happy to patch the EPEL packages to support a backported > curl from RHEL. Feel free to add me to the Cc on that bug. > -- >Todd So going back, all this ticket is asking about is backporting MULTI support into libcurl 7.15, which in Comment 2 said encompassed the following: > - fixing the RHEL5 libcurl by backporting the simple curl.git commit > 2ff609dd43cb5c1c0da893c080132a48a2d4c73b
For the change to be of any relevance, git has to be patched too. Let's be clear if we want this bugzilla to be prioritized correctly: this change is not the backport of MULTI support, but rather the fix of a bug with MULTI support (in curl_multi_remove_handle()). Moreover we can see a "placeholder" where the patch would have to be applied in curl 7.15.0: --- 8< --- /* If the 'state' is not INIT or COMPLETED, we might need to do something nice to put the easy_handle in a good known state when this returns. */ --- >8 --- Based on https://github.com/blog/642-smart-http-support we can trivially test this feature with github.com repos. I will bake a test myself ASAP.
I hacked around a git build issue by removing the .desktop file installation entirely: --- 8< --- + desktop-file-install --dir=/var/tmp/git-1.7.4.1-1.688871-root-root/usr/share/applications /usr/src/redhat/SOURCES/git-gui.desktop Must specify the vendor namespace for these files with --vendor error: Bad exit status from /var/tmp/rpm-tmp.41946 (%install) --- >8 --- Other than that my test packages are as straightforward as assumed in comment #2. You can find them on http://people.redhat.com/~pcarrier/rhbz688871/ They are meant for test purposes only, should not be used in any production environment. They will not be officially supported by Red Hat, Inc. Worked fine for me: --- 8< --- # git push Password: Counting objects: 5, done. Writing objects: 100% (3/3), 252 bytes, done. Total 3 (delta 0), reused 0 (delta 0) To https://pcarrier@github.com/pcarrier/test.git c12007b..7c99b24 master -> master --- >8 ---
As far as I understand this bug report, it is not an RFE, but a regular bug fix. MULTI support simply cannot be added to curl, since it is already there.
Created attachment 522077 [details] backport of upstream 2ff609d
Created attachment 522080 [details] RHEL-5 specfile with the patch added
Created attachment 522081 [details] an SRPM for testing purposes
I built patched curl and git packages for EL-5 (x86_64 only) and did some light testing. Here's a short procedure to test: # Grab the patched packages $ sudo curl -o /etc/yum.repos.d/tmz-git-curl-multi.repo http://tmz.fedorapeople.org/repo/tmz-git-curl-multi/tmz-git-curl-multi.repo $ sudo yum --enablerepo tmz-git-curl-multi --disablerepo Gaggle-CentOS install git httpd # Setup a bare repo that the apache user can read/write $ cd /var/www/html $ sudo git init --bare --shared test.git $ sudo chgrp -R apache test.git $ cd test.git $ sudo mv hooks/post-update{.sample,} $ sudo git update-server-info # Enable DAV support $ cat /etc/httpd/conf.d/git.conf <Location /test.git> DAV on </Location> $ sudo service httpd start # Clone the repo, make some commits, and push them $ cd /tmp $ git clone http://localhost/test.git $ cd test $ echo testing > testing $ git add . $ git commit -m testing $ git push origin master Fetching remote heads... refs/ refs/heads/ refs/tags/ updating 'refs/heads/master' from 0000000000000000000000000000000000000000 to 195e6e8be1c88beee4fd204e162b8c8127c7d3e8 sending 3 objects done Updating remote server info To http://localhost/test.git * [new branch] master -> master All this work, and I have to wonder why anyone would really want to use the old DAV-based http push when the "smart" http support has been in git since 1.6.6 and works much better. Really, that's the proper way to achieve this. I didn't realize sooner that this curl deficiency only impacted the old DAV http-push, as far as I can tell.
(In reply to comment #29) > All this work, and I have to wonder why anyone would really want to use the old > DAV-based http push when the "smart" http support has been in git since 1.6.6 > and works much better. Really, that's the proper way to achieve this. I > didn't realize sooner that this curl deficiency only impacted the old DAV > http-push, as far as I can tell. I'll take the fall on that one. When I looked up how to do git over http, the DAV-based is the documentation I found. Didn't find anything talking about smart http, and thats the first I've heard of it.
Todd, thank you for testing the packages and the detailed howto. I have no problem with applying that one-line patch on curl, even though this bug appeared to have a reasonable workaround. If anybody has another opinion, please shout now.
No worries. For reference, see git-http-backend(1), and http://progit.org/2010/03/04/smart-http.html When kernel.org is back up: http://www.kernel.org/pub/software/scm/git/docs/ has the man page online as well.
so... SmartHTTP works great...
SanityOnly. All regression and sanity test executed. If we get positive response from customer we can update this bug with that.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0241.html