Debian: fails to build in backports

[utkarsh2102]

Hi @zyedidia,

Whilst backporting 2.0.6 to stable (via buster-backports), I couldn't build it. It fails with the following (snipped) logs:
I am not sure what's causing this, any clue?

I can only think of a dependency mismatch. But not sure which one.
(and I don't think it's go-humanize)

<snip>
crypto/tls
github.com/zyedidia/micro/pkg/highlight
github.com/zyedidia/micro/internal/lua
# github.com/zyedidia/micro/internal/lua
src/github.com/zyedidia/micro/internal/lua/lua.go:569:48: undefined: humanize.FtoaWithDigits
net/http/httptrace
net/http
dh_auto_build: cd obj-x86_64-linux-gnu && go install -gcflags=all=\"-trimpath=/<<PKGBUILDDIR>>/obj-
x86_64-linux-gnu/src\" -asmflags=all=\"-trimpath=/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/src\" -v -p 8
-buildmode=pie "-ldflags=-extldflags -Wl,-z,now -s -w -X 'github.com/zyedidia/micro/v2/internal/util.Version=
2.0.6' -X 'github.com/zyedidia/micro/v2/internal/util.CommitHash=' -X 'github.com/zyedidia/micro/v2/internal
/util.CompileDate=' " github.com/zyedidia/micro/cmd/micro returned exit code 2

[zyedidia]

It must be go-humanize, but that is quite surprising since the version of the go-humanize dependency did not change with 2.0.6. Are you sure that you are using go-humanize v1.0.0?

[utkarsh2102]

I am very sure!
See: https://tracker.debian.org/pkg/golang-github-dustin-go-humanize
There's v1.0.0 in unstable, testing, and backports! That's why I am surprised too.

However, let me also state that the version of micro in backports is 2.0.3. And I am going to introduce 2.0.6.
Did any version of dependency change since then except tcell?

Because for v2.0.6 of micro, I just had to bump tcell to it's latest version and the build was clean in unstable.
So now, I have backported tcell and when I am trying to backport micro v2.0.6, it fails to build as shown above^^ :/

[zyedidia]

There have been some updates to the dependencies since 2.0.3, but none of them (other than tcell) change the outward interface or any of the import names in the micro source code, so I don't think updating them should be necessary. None of them should cause this error either since they have nothing to do with go-humanize. The changes are

• zyedidia/clipboard updated from v0.0.0-20190823154308-241f98e9b197 to 20200421031010-7c45b8673834.
• kballard/go-shellquote is replaced with zyedidia/go-shellquote. This only changes behavior on Windows, so including this change should not be necessary for Debian, and using kballard/go-shellquote should build without errors.
• mattn/go-runewidth is replaced with p-e-w/go-runewidth. This change improves performance, but does not change the interface and it should be possible to build using mattn/go-runewidth without errors.

Since the changes to go-shellquote and go-runewidth are made in go.mod by using the replace directive, these replacements shouldn't cause any build errors.

I'm not sure if this is possible, but if you delete the code in src/github.com/zyedidia/micro/internal/lua/lua.go on line 569 (the line causing the error), does it build cleanly?

[utkarsh2102]

I'm not sure if this is possible, but if you delete the code in src/github.com/zyedidia/micro/internal/lua/lua.go on line 569 (the line causing the error), does it build cleanly?

Wow, it does build fine now!
Many thanks! \o/

Would you want to remove it from here as well, if it's not doing anything useful?
(I'd be happy to raise a pull request if so!? 😄)

[zyedidia]

I have no idea why that would be. Sure you can open a PR to remove it, and you can remove the line above it too (the one with humanize.Ftoa). The line is just exposing that function from humanize to plugins, but I think the same behavior can be achieved with fmt.Sprintf which is already exposed, and I'm quite certain that no plugin is using FtoaWithDigits or Ftoa. It was probably a bad idea to decide to expose them to plugins in the first place. The PR should also remove those functions from the documentation in runtime/help/plugins.md (lines 367-368). Thanks!

[zyedidia]

While I have you here, I think the version of micro in the Ubuntu focal repositories is still 2.0.1. Is it possible to upgrade it to 2.0.6 as you have done for Debian buster? Thank you greatly for your help.

[utkarsh2102]

@zyedidia, hi,
I'm not sure if we can bump the version but I'm in midst of fixing those issues that we discussed earlier in Ubuntu.

I'll definitely try to bump the version but not sure how Ubuntu folks would react to it.
But I'll give you some more (and hopefully nice) updates this weekend! 😄

[zyedidia]

Sounds good, thanks!

[utkarsh2102]

Hi,

I am sorry I forgot to update 🤦‍♂️

The version cannot be upgraded in the stable release, focal. That's a no-go.
So there are two things here:

• Fix whatever bug is there in v2.0.1 in Ubuntu.
• Somehow, backport v2.0.6 to focal-backports (not focal!).

[zyedidia]

Thanks for the update! It seems like backporting to focal-backports is the best option. Is this difficult to do?

What do you mean by fix whatever bug is in v2.0.1 in Ubuntu? Is it possible to modify the build script after the fact? If so, the best thing would be to add -X github.com/zyedidia/micro/internal/util.Debug=OFF to the go build invocation. Of course, getting v2.0.6 into focal-backports would be better anyway because of the improvements since v2.0.1.

[utkarsh2102]

Thanks for the update! It seems like backporting to focal-backports is the best option. Is this difficult to do?

A bit, I think. I am going to have to devote some time to get this going.

What do you mean by fix whatever bug is in v2.0.1 in Ubuntu?

I read somewhere that the version of Micro in Ubuntu has some bug that needs fixing, not sure which issue was it.

Is it possible to modify the build script after the fact? If so, the best thing would be to add -X github.com/zyedidia/micro/internal/util.Debug=OFF to the go build invocation.

I see, yeah. When I do this, I'll give you a ping with the changes that I am making.

Of course, getting v2.0.6 into focal-backports would be better anyway because of the improvements since v2.0.1.

Yeah, right, of course!

[zyedidia]

Great, thank you so much!

[zyedidia]

Just wanted to ping this to see if there was an update, and because I'm planning on releasing 2.0.7 soon. Fixing the build script for 2.0.1 is the most important though, and hopefully it's not too complex.