python312Packages.hvplot: fix checks on darwin
fix checkphase on darwin to not access the display
(cherry picked from commit 9e5774c4e3)
Co-authored-by: Reno Dakota <paparodeo@proton.me>
Enabling LTO causes test failures when compiling for x86_64-darwin (at
least under Rosetta 2). The Nix package only enables LTO when using GCC,
so we'll copy that for now. I don't feel safe leaving it on for
aarch64-darwin unless we can understand why it's failing on
x86_64-darwin in case this is an indication of UB.
Fixes#337036.
(cherry picked from commit 1ed59a4eb8)
The current default configuration, automatic channel selection with
the HT40- capability, is explicitly disallowed by an assertion in this
module.
This is a result of recent change to default to automatic channel
selection in 1047f0a6bf.
(cherry picked from commit 8a97d662dd)
The workaround to have ofborg ping chromium and ungoogled-chromium
maintainers when a change was only made to the upstream-info relied on
string context.
That string context was provided by the upstream-info being a nix file,
not a json file, and then holding on to that string context using
awkward attribute merges.
It was intended as a quick fix until the handling of this would improve
in ofborg itself and worked great.
That was until very recently when we switched from the chromium release
tarball to git source fetching in 8dd2f1add9.
Part of that change included going back from upstream-info.nix to
upstream-info.json and with that losing the string context and the base
on which this workaround used to work.
But this is fine. A lot has happened in the meantime.
CODEOWNERS was reimplemented and no longer requires every user listed in
it to have write permissions to the repository (commit bit).
Meaning we can accept that ofborg pings no longer work and instead rely
on CODEOWNERS exclusively.
It should, however, be noted that CODEOWNERS provide less granularity
than ofborg, meaning we can no longer differentiate between
ungoogled-chromium and chromium or even chromedriver.
Previously, implementing the workaround that is now essentially
reverted: 68c59791fb
(cherry picked from commit 674835a9d9)
I'm including the steps I took to update this package to help the next
committer. Time permitting, this should probably be codified as a
formal update script:
1. Clone the upstream hashicorp/vagrant repository
2. Check out the desired version tag
3. Run `bundle lock` within the repository to generate `Gemfile.lock`
4. Run `bundix` to generate a `gemset.nix`
5. Move `gemset.nix` to overwrite this package's `gemset.nix`
6. Remove the self-referential `vagrant` attribute of the gemset
7. Clone vagrant-libvirt/vagrant-libvirt and check out the desired tag (probably latest release tag)
8. (Maybe optional?) because `bundle lock` lacks the ability to exclude groups; comment out groups unrelated to a release like `development` and `test, otherwise dependency conflicts with vagrant's `gemset.nix` are likely.
9. Run `bundle lock` within the repository to generate `Gemfile.lock`
10. Run `bundix` to generate a `gemset.nix`
11. Move `gemset.nix` to overwrite this package's `gemset_libvirt.nix`
12. Edit the `vagrant-libvirt` gem attribute to change its source to rubygems and not a relative path
Aside from these specific steps, the normal package update steps apply (update version, set hash to `lib.fakeHash`, get the updated hash to replace the old).
(cherry picked from commit 3cb2fa6e00)
Ofborg also does this.
Should be run on `lib/*` dirs
Signed-off-by: John Titor <50095635+JohnRTitor@users.noreply.github.com>
(cherry picked from commit 6da0724cf3)
