Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cri-o: 1.17.3 -> 1.18.0 #85869

Merged
merged 1 commit into from
Apr 28, 2020
Merged

cri-o: 1.17.3 -> 1.18.0 #85869

merged 1 commit into from
Apr 28, 2020
+6 −12

Conversation

saschagrunert
Copy link
Member

@saschagrunert saschagrunert commented Apr 23, 2020 •
edited
Loading

Motivation for this change

Update CRI-O to the latest version.

This won't build because I need at least go 1.13 for this. @zowoq @marsam @vdemeester do you know if I can enforce a specific go version for buildGoPackage?

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

Sorry, something went wrong.

@saschagrunert
Copy link
Member Author

@GrahamcOfBorg build cri-o

@vdemeester
Copy link
Member

@saschagrunert Also I can see that cri-o switch to using go modules, so we should be able to use buildGoModule in this derivation, shouldn't we ? 👼

@marsam
Copy link
Contributor

marsam commented Apr 23, 2020

you may need to remove this line:

nixpkgs/pkgs/top-level/all-packages.nix

Line 23310 in f02a129

buildGoPackage = buildGo112Package;

@Mic92
Copy link
Member

Mic92 commented Apr 23, 2020

@GrahamcOfBorg eval

1 similar comment
@jonringer
Copy link
Contributor

@GrahamcOfBorg eval

@ofborg ofborg bot added 11.by: package-maintainer This PR was created by the maintainer of the package it changes 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 1-10 10.rebuild-linux: 1 labels Apr 23, 2020
@zowoq
Copy link
Contributor

zowoq commented Apr 23, 2020

@saschagrunert Do you want to add the commit from #85682 to this PR?

@srhb
Copy link
Contributor

srhb commented Apr 24, 2020 •
edited
Loading

do you know if I can enforce a specific go version for buildGoPackage?

Easiest is probably buildGo113Package (or buildGo113Module if you go down that route)

@saschagrunert saschagrunert mentioned this pull request Apr 24, 2020
Closed
10 tasks
@saschagrunert
Copy link
Member Author

saschagrunert commented Apr 24, 2020 •
edited
Loading

Thank you for all of your hints! I picked in the changes of #85682, using now buildGoModule and switched to the standard go version as well.

@GrahamcOfBorg eval

The configuration in the module has to be changed as well, but I'd like to do that in another PR.

@zowoq
Copy link
Contributor

zowoq commented Apr 24, 2020 •
edited
Loading

I don't think buildGoModule is needed as the go deps are already vendored?

@ofborg ofborg bot requested a review from kalbasit April 24, 2020 07:40
@vdemeester
Copy link
Member

I don't think buildGoModule is needed as the go deps are already vendored?

Right, I thought of that too after commenting 😅. With go 1.14, go build will use the vendor folder if it's present (à-la go build -mod=vendor). I wonder if long-term we should have only one buildGo… function that would support all the thing 👼.

@saschagrunert
Copy link
Member Author

I don't think buildGoModule is needed as the go deps are already vendored?

Yeah but since buildGoPackage is explicitly mentioned as "legacy" I still would like to stick to the new way. WDYT?

@vdemeester
Copy link
Member

I don't think buildGoModule is needed as the go deps are already vendored?

Yeah but since buildGoPackage is explicitly mentioned as "legacy" I still would like to stick to the new way. WDYT?

Maybe but I don't think we should hold merge this bump for that 👼 (it could be done as a follow-up)

@saschagrunert
cri-o: 1.17.3 -> 1.18.0
1ae9631 
- Make buildtags being able to set via the BUILDTAGS environment
- Switch to go 1.14

Signed-off-by: Sascha Grunert <sgrunert@suse.com>
@saschagrunert
Copy link
Member Author

Okay cool I reverted some of my changes and sticked to buildGoPackage

@zowoq
Copy link
Contributor

zowoq commented Apr 28, 2020

Could a committer merge this please? cc @marsam @Mic92

@marsam marsam merged commit ce7272b into NixOS:master Apr 28, 2020
@saschagrunert saschagrunert deleted the crio branch April 29, 2020 07:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@zowoq zowoq

@kalbasit kalbasit

Assignees
No one assigned
Labels
10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 1-10 10.rebuild-linux: 1 11.by: package-maintainer This PR was created by the maintainer of the package it changes
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
7 participants
@saschagrunert @vdemeester @marsam @Mic92 @jonringer @zowoq @srhb