Hello there,

Since Go 1.17 is now the defaults on the archive this package
fails to build.

It could be great to update to upstream 4.43.0 and backport the
following commit [1] in order to make the package build again.

Cheers,

[1]: https://github.com/v2fly/v2ray-core/commit/77b88171d6bd837b76a5ad6e6b23689391530ed6

Hello there, I hope you are doing fine!

I don't know if you recall me, but we've worked a bit together
on Go packages in the past (alois@micard.lu). :)

I have a request regarding golang-v2ray-core:

The package will be removed on 01-12-21 because of error with Go 1.17
which is now the defaults in the archive.

I wanted to update golang-v2ray-core to latest upstream (4.43.0) and backport
the commit https://github.com/v2fly/v2ray-core/commit/77b88171d6bd837b76a5ad6e6b23689391530ed6
in order to get the package to build with Go 1.17 and allow transition to testing of
golang-github-lucas-clemente-quic-go which is needed to prevent Syncthing from being
RM of testing.

The thing is: the Salsa repository for golang-v2ray-core doesn't have upstream branch,
therefore I'm unable to import new upstream via gbp:


```
creekorful@debuild:~/code/golang-v2ray-core$ gbp import-orig --uscan
gbp:error:
Repository does not have branch 'upstream' for upstream sources. If there is none see
file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT
on howto create it otherwise use --upstream-branch to specify it.
```

Have you forgot to push upstream branch to Salsa? Or are you using a special workflow?

If you can either import latest upstream or push missing upstream branch it would
be greatly helpful.

Many thanks.

Cheers,

Dear Aloïs,

Thanks for your work to go packages!
Sorry I don't have time lately. So if you can update the packages and
fix the RC bugs, it'd be appreciated.

Cheers,
Roger

Hello Roger,
repository? It looks like there's none and therefore `gbp import-orig --uscan`
is failing:

```
creekorful@debuild:~/code/golang-v2ray-core$ gbp import-orig --uscan
gbp:error: Repository does not have branch 'upstream' for upstream sources. If there is none see
file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT
on howto create it otherwise use --upstream-branch to specify it.
```

It could be really helpful if you either push upstream branch or explain me
which workflow you are using.

Cheers,

Dear Aloïs,

Personally I don't use upstream branch, and I don't think it's necessary.
But if it meet your workflow, I don't have objectection to add this branch.

My workflow is simple:
- use "uscan -dd" to download latest or specified upstream tarball
- merge debian (or master) branch with upstream tag. Maybe removing
some files in "excluded" of d/copyright is necessary.
- use gbp command to build

Hope it helps.

Cheers,
Roger

I have tried to upgrade to the latest upstream (4.45) today, and failed
at the first patch because it doesn't apply. I refreshed the other two
patches and I'm waiting to hear from upstream (in CC) how to deal with
the first. I pushed my work to the debian/experimental branch on salsa:

https://salsa.debian.org/go-team/packages/golang-v2ray-core/-/merge_requests/new?merge_request%5Bsource_branch%5D=debian%2Fexperimental

a.

The aim of the first patch is to remove VSign signature verification,
which requires additional dependency. It is designed to verify
upstream's binary release and is useless on distributions since
distributions neither creates the same binary(requires replicating
upstream's reproducible build and applying no patching) nor generate its
own signature. The original opengpg signature verification is no longer
useful as we no longer create gpg signatures of our binary(gpg
signatures do not include and verify filename or other context
information in our old signature formats, this would allow an attacker
to swap binaries of different versions).

This file can be simply deleted to remove verify command. (patch 1)


In addition to this, to remove dependency on VSign, executable resource
integrity protection is also removed(patch 3). (This is not only
designed to prevent someone from running that in an unsandboxed
electron, but make sure we won't have merge conflict with the user's own
version of these scripts when we update it. So removing it shouldn't
create too many issues in Debian's case.)


To remove dependency on github.com/jhump/protoreflect, an engineering
feature dynamic protojson loading is removed(not very useful for
end-users)(patch 2). It is used to help users with a customized build of
V2Ray that have configuration elements that cannot be represented by
jsonv4 format, not distribution users.

[context for the list: I'm working on upgrading the golang-v2ray-core
package to the latest upstream. i'm kind of stuck on a problem I can't
figure out.]

Thanks, those patch are great. I think it might be better to use build
tags to disable that functionality than to rip it out with a patch, but
I'm happy to carry the patch set for now.

It also seems to work, to the extent that the patch applies and I can
get further in the build. I had to disable protobuf regeneration because
that was failing with an error:

Regenerate v2ray.com/core/app/reverse/config.proto
github.com/v2fly/v2ray-core/v4/app/reverse/config.pb.go: while trying to create directory ./github.com/v2flyRegenerate v2ray.com/core/app/browserforwarder/config.proto
: Permission denied

This could just be a tooling issue on our side, but there's a newer
protobuf dep in experimental that we can use for now, so I dodged that
problem by targeting experimental for now.

The next hurdle is that the build fails on what looks like a go mod
issue:

make[1]: Entering directory '/<<PKGBUILDDIR>>'
DH_GOPKG="v2ray.com/core/main" dh_auto_build -- -ldflags "-s -w -buildid= -X v2ray.com/core.codename=user -X v2ray.com/core.build=20220505-203716 -X v2ray.com/core.version=4.45.0"
	cd obj-x86_64-linux-gnu && go install -trimpath -v -p 2 -ldflags "-s -w -buildid= -X v2ray.com/core.codename=user -X v2ray.com/core.build=20220505-203716 -X v2ray.com/core.version=4.45.0" v2ray.com/core/main v2ray.com/core/main/confloader v2ray.com/core/main/confloader/external v2ray.com/core/main/distro/all v2ray.com/core/main/distro/debug v2ray.com/core/main/json v2ray.com/core/main/jsonem
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
src/v2ray.com/core/main/main.go:17:2: cannot find package "github.com/v2fly/v2ray-core/v4" in any of:
	/usr/lib/go-1.18/src/github.com/v2fly/v2ray-core/v4 (from $GOROOT)
	/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/src/github.com/v2fly/v2ray-core/v4 (from $GOPATH)

... there's a bunch more of those, naturally.

Dear Debian go folks, how do we typically solve those issues?

Do we have any other "go mod" package around? How do they handle those
problems?

Build log is attached, code lives in the debian/experimental branch on
salsa:

https://salsa.debian.org/go-team/packages/golang-v2ray-core/-/tree/debian/experimental

Thanks!

Quick update on this, zhsj on IRC pointed out upstream changed their
import path, so that fixed most of the import problems. We're left with:

github.com/v2fly/BrowserBridge/handler github.com/v2fly/ss-bloomring inet.af/netaddr

make[1]: Entering directory '/<<PKGBUILDDIR>>'
DH_GOPKG="github.com/v2fly/v2ray-core/main" dh_auto_build -- -ldflags "-s -w -buildid= -X v2ray.com/core.codename=user -X v2ray.com/core.build=20220505-203716 -X v2ray.com/core.version=4.45.0"
	cd obj-x86_64-linux-gnu && go install -trimpath -v -p 2 -ldflags "-s -w -buildid= -X v2ray.com/core.codename=user -X v2ray.com/core.build=20220505-203716 -X v2ray.com/core.version=4.45.0" github.com/v2fly/v2ray-core/main github.com/v2fly/v2ray-core/main/confloader github.com/v2fly/v2ray-core/main/confloader/external github.com/v2fly/v2ray-core/main/distro/all github.com/v2fly/v2ray-core/main/distro/debug github.com/v2fly/v2ray-core/main/json github.com/v2fly/v2ray-core/main/jsonem
src/github.com/v2fly/v2ray-core/app/browserforwarder/forwarder.go:14:2: cannot find package "github.com/v2fly/BrowserBridge/handler" in any of:
	/usr/lib/go-1.18/src/github.com/v2fly/BrowserBridge/handler (from $GOROOT)
	/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/src/github.com/v2fly/BrowserBridge/handler (from $GOPATH)
src/github.com/v2fly/v2ray-core/common/antireplay/bloomring.go:6:2: cannot find package "github.com/v2fly/ss-bloomring" in any of:
	/usr/lib/go-1.18/src/github.com/v2fly/ss-bloomring (from $GOROOT)
	/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/src/github.com/v2fly/ss-bloomring (from $GOPATH)
src/github.com/v2fly/v2ray-core/app/router/condition_geoip.go:7:2: cannot find package "inet.af/netaddr" in any of:
	/usr/lib/go-1.18/src/inet.af/netaddr (from $GOROOT)
	/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/src/inet.af/netaddr (from $GOPATH)
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
dh_auto_build: error: cd obj-x86_64-linux-gnu && go install -trimpath -v -p 2 -ldflags "-s -w -buildid= -X v2ray.com/core.codename=user -X v2ray.com/core.build=20220505-203716 -X v2ray.com/core.version=4.45.0" github.com/v2fly/v2ray-core/main github.com/v2fly/v2ray-core/main/confloader github.com/v2fly/v2ray-core/main/confloader/external github.com/v2fly/v2ray-core/main/distro/all github.com/v2fly/v2ray-core/main/distro/debug github.com/v2fly/v2ray-core/main/json github.com/v2fly/v2ray-core/main/jsonem returned exit code 1

... I guess those would need to be packaged as well. Or vendored?
Opinions on that?

control: tags -1 -ftbfs
control: severity -1 normal

I think currently there's no ftbfs issue for this package.
So no immediate urgency to upgrade package.

It's still welcome that anyone can help to package the new
dependencies to NEW queue.
Thanks for the work from you all!

Cheers,

control: block -1 by 980432 1130924 1130931
thanks

control: block -1 by 980432 1130924 1130931 1130934
thanks