Latest buildroot (1) will not download git versions in x/y properly. Instead, it will try to download x_y. This was working fine with an old commit (2). After bisecting, it seems that commit 54456cc6982598fa45e7c97609e83fabec7c1695 broke it. Best regards, V. (1) latest commit f67e7ba06f5f00dc9153ad364932092692458704 (2) old commit 249464674485ed1fa18a2d0dd5500c84198490b9
Please be more specific: what do you mean with 'in x/y' ? Please give an example and/or a reproduction scenario.
(In reply to comment #1) > Please be more specific: what do you mean with 'in x/y' ? In my case I set <PKG>_VERSION in a .mk to my development branch: FOO_VERSION = vincent/dev > Please give an example and/or a reproduction scenario. I'll try to devise a quick test case with a public git tree to demonstrate. V.
(In reply to comment #2) > Please give an example and/or a reproduction scenario. Ok, here is a quick test case to demonstrate the issue: In package/dtc/dtc.mk, change: DTC_VERSION = refs/tags/v1.4.0 Then do: make defconfig make dtc-source This works on 249464674485ed1fa18a2d0dd5500c84198490b9, but not after 54456cc6982598fa45e7c97609e83fabec7c1695. V.
Confirmed. Here is a tentative patch to ifix the issue. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk index fb4b849..d04fd36 100644 --- a/package/pkg-generic.mk +++ b/package/pkg-generic.mk @@ -318,14 +318,14 @@ $(2)_RAWNAME = $$(patsubst host-%,%,$(1)) # version control system branch or tag, for example remotes/origin/1_10_stable. ifndef $(2)_VERSION ifdef $(3)_VERSION - $(2)_DL_VERSION = $$($(3)_VERSION) + $(2)_DL_VERSION := $$($(3)_VERSION) $(2)_VERSION := $$(subst /,_,$$($(3)_VERSION)) else $(2)_VERSION = undefined $(2)_DL_VERSION = undefined endif else - $(2)_DL_VERSION = $$($(2)_VERSION) + $(2)_DL_VERSION := $$($(2)_VERSION) $(2)_VERSION := $$(subst /,_,$$($(2)_VERSION)) endif
(In reply to comment #4) > Here is a tentative patch to ifix the issue. This patch repairs my builds. Thank you very much, Yann! V
Patch sent to the list: http://patchwork.ozlabs.org/patch/381411/
Fixed by Yann in 1939011ce6f5cf, thanks