Bug 6475 - SVN fetcher removes username from URI inappropriately
Summary: SVN fetcher removes username from URI inappropriately
Status: RESOLVED FIXED
Alias: None
Product: BitBake
Classification: Build System, Metadata & Runtime
Component: bitbake (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium normal
Target Milestone: 1.7
Assignee: Richard Purdie
QA Contact:
URL:
Whiteboard: 3 July 2014: Doc flag set to "Done"
Depends on:
Blocks:
 
Reported: 2014-06-24 15:25 UTC by William R. Otte
Modified: 2014-07-07 05:49 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Done (doc changes complete)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description William R. Otte 2014-06-24 15:25:12 UTC
Given the following srcuri in a recipe:

SRC_URI = "svn://git@svn.example.com/path/to/repo;module=path/to/module;protocol=svn+ssh"

the svn fetcher generates the following command:

svn --non-interactive --trust-server-cert log --limit 1 --no-auth-cache --username git svn+ssh://svn.example.com/path/to/repo/path/to/module/

This causes svn to connect as the current user instead of the specified username, causing the command to fail.  

I would expect that it would generate the following command:

svn --non-interactive --trust-server-cert log --limit 1 --no-auth-cache  svn+ssh://git@svn.example.com/path/to/repo/path/to/module/

In my mind, the svn fetcher is being too clever for its own good: the former generated command should only be generated if I append "user=git" to the SRC_URI.
Comment 1 Richard Purdie 2014-06-26 09:42:40 UTC
Well, this is a really tricky one. Rightly or wrongly, the fetcher defines the username in the url to be the username parameter to pass to svn. Until now its never evidently been needed to have two different usernames, one for the transport and one for svn itself.

We have a backwards compatibility problem, I'd suggest we add a parameter to specify the transport username for a case like this.
Comment 2 William R. Otte 2014-06-26 14:53:42 UTC
That would be sufficient for my purposes; the only comment I have is that if the current behavior is kept (foo@ generates --user foo), and my use case was the intended behavior, the reason for the failure isn't intuitive. 

I'd suggest deprecating user@ behavior entirely.
Comment 3 Richard Purdie 2014-07-03 10:41:20 UTC
There is a patch out for review on bitbake-devel. It adds a transportuser parameter to svn urls, the bitbake manual will need updating with this new parameter. A description is:

"A parameter to set the username to use for the transport if required, defaulting to empty. This is different to the username used in the main url which is passed to the subversion command."
Comment 4 Scott Rifenbark 2014-07-03 14:49:10 UTC
Here is a doc change for the bug.  http://www.yoctoproject.org/docs/1.7/bitbake-user-manual/bitbake-user-manual.html#svn-fetcher

Please check it over.

Scott
Comment 5 William R. Otte 2014-07-03 17:11:56 UTC
This all seems reasonable to me.  Thanks for the quick action folks.
Comment 7 Scott Rifenbark 2014-07-07 05:49:13 UTC
Set the doc flag to "Done".

Scott