[yocto] TFS Urls with Git in Recipes

[Lohr, Christian [ext]]

Hello Randy,

Thanks for your reply and your efforts.
I already solved my issue and renamed the project from "FooBar 500" to "FooBar_500". This was the easiest and fastest solution. And luckily nobody complained after the renaming.

Before that I also tried that one (both of them), but it didn't work:

> It's possible that:
>     PROJECT_NAME = "FooBar 500"
> or
>     PROJECT_NAME = "FooBar\ 500"
> would work.


-----Ursprüngliche Nachricht-----
Von: Randy MacLeod <randy.macleod at windriver.com> 
Gesendet: Freitag, 25. Oktober 2019 21:33
An: Lohr, Christian [ext] <christian.lohr.ext at zeiss.com>; yocto at yoctoproject.org
Betreff: Re: [yocto] TFS Urls with Git in Recipes

Hello Christian,

Thanks for reporting the problem. Comments and questions below.

On 10/23/19 3:36 AM, Lohr, Christian [ext] wrote:
> Hello,
> 
> I‘m using the following:
> 
> Yocto Release 2.4 (Rocko), and Bitbake 1.9.x

Can you check if the problem is still present on the master branch?

> 
> My problem is the following url (actually the “%20” is the problem in
> bitbake):
> 
> ssh://tfs-my-company.org:22/tfs/OWN_Projects/FooBar%20500/_git/DummyAp
> plicationForYocto
> 
> I can do a “git clone <url>” without any problems. Now I wanted to 
> create a Yocto recipe similar to this:
> 
> ----------------------------------------------------------------------
> --------------------------------------------------------------------
> 
> SUMMARY = "A demo application"
> 
> DESCRIPTION = "This application is just for demo purpose and should be 
> seen as Hello World"
> 
> LICENSE = "CLOSED"
> 
> #LIC_FILES_CHKSUM = ""
> 
> PROJECT_URL = "tfs-my-company.org:22/tfs/OWN_Projects"
> 
> PROJECT_NAME = "FooBar%20500"

It's possible that:
     PROJECT_NAME = "FooBar 500"
or
     PROJECT_NAME = "FooBar\ 500"
would work. Have you tried that already? I haven't worked on the bitbake fetcher code so I may be making naive suggestions.

Also, I expect that you are working around the issue by just removing the space in the path, right?

> 
> SRC_URI =
> "git://${PROJECT_URL}/${PROJECT_NAME}/_git/DummyApplicationForYocto;protocol=ssh"
> 
> SRCREV = "${AUTOREV}"
> 
> PV = "1.0+git${SRCPV}"
> 
> DEPENDS = "qtbase"
> 
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 
> The „%20“ sign will be replaced with a space “ “ in some cases:
> 
> When I try to run “bitbake dummyapp”, the following happens:
> 
> “FooBar%20500” will be transformed to “FooBar 500”
> 
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 
> git -c core.fsyncobjectfiles=0 ls-remote 
> ssh://tfs-my-company.org:22/tfs/OWN_Projects/FooBar
> 500/_git/DummyApplicationForYocto  failed with exit code 128, output:
> 
> remote: Command git-upload-pack '/tfs/OWN_Projects/FooBar' is not in 
> expected format.
> 
> fatal: Could not read from remote repository.
> 
> Is it possible to prevent this because if it would leave the “%20” the 
> command would work.


The YP does have problems dealing with spaces in path names as you have seen. I think this prevents the MacOS port for example.

Could you open a defect in the Yocto bugzilla?
   https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.yoctoproject.org%2F&data=02%7C01%7C%7C73e5d9d6551a4ca871fe08d7598230fb%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637076288017573764&sdata=3OgKQDXnzp2D6wKZdZuhgVMGkMVv%2B7pjCGfWWSk1AIs%3D&reserved=0
   https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.yoctoproject.org%2Fwiki%2FBug_reporting_and_Information_levels&data=02%7C01%7C%7C73e5d9d6551a4ca871fe08d7598230fb%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637076288017573764&sdata=aQW%2Fzc7M8ZSU4yvPiiAxhev8P%2BatdmiV5XgGgW8KviM%3D&reserved=0

Ideally, it would be great if you could submit a patch but I understand that you may not have the time, interest or the expertise to do so.
If you are not able to do that then the defect will be triaged during the weekly review (next week's meeting is actually cancelled do to the Embedded Linux Conference - Europe) and someone will work on the defect based on it's importance and their interest and workload.

If you want a fix sooner than that, there are companies and consultants listed on the yocto project homepage:
    https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.yoctoproject.org%2Fecosystem%2Fmembers%2F&data=02%7C01%7C%7C73e5d9d6551a4ca871fe08d7598230fb%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637076288017573764&sdata=%2F%2BhOUitRQRUvwpjk954BlOQtb3d5WIzsgrwjAsdAj0c%3D&reserved=0
    https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.yoctoproject.org%2Fcommunity%2Fconsultants%2F&data=02%7C01%7C%7C73e5d9d6551a4ca871fe08d7598230fb%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637076288017573764&sdata=%2FOLhvIdhf%2FH%2BIfe09taOjhyDiDfaPBmO%2BPq0TDJbzwQ%3D&reserved=0

Thanks again for the report and
I'm sorry that I'm not able to be of more help immediately.

../Randy



> 
> Kind regards,
> 
> Christian Lohr
> 
> 


--
# Randy MacLeod
# Wind River Linux