Outdated vendor/golang.org software

[tuxillo]

• Gitea version (or commit ref): 1.5.0
• Git version:
• Operating system:
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

While trying to build gitea on other OSes (SmartOS, NetBSD, ...) I encountered some errors and after checking, it is related to the golang/sys version gitea distributes. Apparently it hasn't been updated in a while.

I've based the list below in the "revisions" found in Gopkg.lock which I assume they were generated by some command based on Gopkg.toml.

Vendor software	Date	Version
golang.org/x/sys	2016-07-15	golang/sys@a646d33
golang.org/x/oauth2	2016-08-25	golang/oauth2@c10ba27
golang.org/x/net	2017-01-14	golang/net@f249948
golang.org/x/sync	2017-03-17	golang/sync@5a06fca
golang.org/x/text	2017-06-17	golang/text@2bf8f2a
golang.org/x/crypto	2018-04-18	golang/crypto@12dd70c

Before trying to send a PR for an updated golang.org/x/sys, is there a procedure to correctly upgrade vendor software? I would assume some test need to be run and passed first, etc.

Also, maybe it would be good to have an automatically generated list of the vendor software and dates of the revisions used, just an idea 😃

[techknowlogick]

Thanks for creating this list. The reason specifically golang.org/x/crypto hasn't been upgraded to the latest version is due to golang support. We just dropped support for 1.8, however the last update to crypto was to a version that worked with 1.8 (the upgrade happened before the drop of support).

[techknowlogick]

Update to my comment above: I've created a PR to update the minimum used version of golang used to test the build so now the packages you've mentioned above can be upgraded to an appropriate version.

[tuxillo]

Thanks. So to update the packages above, do you guys use a specific procedure?

[techknowlogick]

Yup, a dep ensure -update golang.org/x/PACKAGE (for each package), and then create a PR. You may need to change the revision in Gopkg.toml first before running the command.

Our lowest supported version of go right now is 1.9 and so if you want to check that the project builds with that version before pushing you can, but the CI will also check. Because of this, the latest commit for these packages may not work, rather than going commit by commit figuring out which commit is good, I start at most recent, see where the build fails then git blame the line where it fail, and skip to the revision before that and repeat until successful.

Also, personally I'd prefer all of these updates in one PR to make it easier to merge, but it is up to you if you want to do one, or many. My preference is not a strong one and I'd be happy to review either way 😄

[tuxillo]

I think I'll work on the updates individually, it's easier for me. I'm going to use the CI as you said, I think it's going to be a better check than my local builds.
I've already opened a PR (#5059). I'll see if I can use your 'git blame' trick.

Thanks!

[tuxillo]

golang.org/x/sys is now updated
golang.org/x/net is now updated

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[tuxillo]

Please do not close, I plan to update the other vendor software.

[tuxillo]

Also update edsrzf/mmap-go for #4799