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.

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

Newtonsoft.Json: 6.0.8 -> 11.0.2 #44478

Closed
wants to merge 3,405 commits into from
Closed

Newtonsoft.Json: 6.0.8 -> 11.0.2 #44478

wants to merge 3,405 commits into from

Conversation

nek0
Copy link
Contributor

@nek0 nek0 commented Aug 4, 2018

Motivation for this change

Package was outdated and needed for OpenRA.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • 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 nox --run "nox-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)
  • Fits CONTRIBUTING.md.

@nek0
Copy link
Contributor Author

nek0 commented Aug 4, 2018

this also fixes #44470

@nek0 nek0 changed the title Newtonjson Newtonsoft.Json: 6.0.8 -> 11.0.2 Aug 5, 2018
Copy link
Member

@samueldr samueldr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the update!

Is it be possible the first two commits (about vym) and the last commit (about monodevelop) were accidentally added to the branch? They don't seem to be related to Newtonsoft.Json changes. (A rebase would probably get rid of your first stow-away commits.)

Purging them from the branch, then squashing/rebasing to master would be necessary to, then, merge this.


As for the update, it removes a bunch of code (no code is good code), so if it doesn't cause issues elsewhere (to be tested) it'll probably be fine.

jtojnar and others added 24 commits August 11, 2018 03:13
When creating a new mobile broadband connection
with the plasma network manager connection editor,
it tries to find a file containing provider
information somewhere in /usr/share/... .
The build recipe contains a patch to fix the lookup path
such that it finds the file in the corresponding package,
probably added due to
#9389 .
The actual lookup path is injected into
the patch file with substituteAll.

With commit a31d98f ,
the variable name used in subsituteAll changed from
mobile_broadband_provider_info to mobile-broadband-provider-info
(underscores in package names turned into dashes).
Apparently, substituteAll can't handle dashes in variable names.
Consequently, the variable name was no longer resolved.
plasma-nm failed to create new mobile broadband connections;
the connection creator silently exited and logged the error
> plasma-nm: Error opening providers file "@mobile-broadband-provider-info@/share/mobile-broadband-provider-info/serviceproviders.xml"

This commit keeps the dashes in package names, but it
restores the underscores in the variable used by substituteAll,
thereby ensuring the variable gets resolved properly.
Until now it's impossible to override the attrs of the actual build
instruction for the `termite` package like this:

```
termite.overrideAttrs (_: {
  # ...
})
```

This issue occurs since the `termite/default.nix` expressions returns
the `symlinkJoin` expression when I override termite (e.g. to provide a
config file).

I recently patched termite and wanted to apply this patch to my local
termite installation in my system config which is impossible this, so
splitting the wrapper and the build instruction into their own files
makes this way easier to maintian.
The latest binutils upgrade silently broke this until it was fixed by
#43531.

So add a test.
@nek0
Copy link
Contributor Author

nek0 commented Aug 11, 2018

sry, something went awry...

@nek0 nek0 closed this Aug 11, 2018
@matthewbauer
Copy link
Member

matthewbauer commented Aug 21, 2018

Does this fix the original issue though? We can just cherrypick c632384 if so.

@nek0
Copy link
Contributor Author

nek0 commented Aug 22, 2018

yes, it fixes the original issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet