i3 loads its configuration from `~/.config/i3`, but in nix-based systems
you might want to build the config in `~/.nix-profile` using a nix
derivation, so `i3` needs to know where to look for the configuration
file.
This commit adds the xen_4_8 package to be used instead of
xen (currently at 4.5.5):
* Add packages xen_4_8, xen_4_8-slim and xen_4_8-light
* Add packages qemu_xen_4_8 and qemu_xen_4_8-light to be used
with xen_4_8-slim and xen_4_8-light respectively.
* Add systemd to buildInputs of xen (it is required by oxenstored)
* Adapt xen service to work with the new version of xen
* Use xen-init-dom0 to initlilise dom0 in xen-store
* Currently, the virtualisation.xen.stored option is ignored
if xen 4.8 is used
Issues addressed:
- xcode build failed with
... was built for newer OSX version (10.10) than being linked (10.5)
fixed by setting GYP mac deployment target to the nix value
- a gyp bug when SDKROOT is not set (and removed an orphaned gyp patch
- path to python in generated gyp-mac-tool
- noisy build due to static assert warnings, by silencing warnings
- use of system xcodebuild and libtool replaced by darwin.cctools
XSA-216 Issue Description:
> The block interface response structure has some discontiguous fields.
> Certain backends populate the structure fields of an otherwise
> uninitialized instance of this structure on their stacks, leaking
> data through the (internal or trailing) padding field.
More: https://xenbits.xen.org/xsa/advisory-216.html
XSA-217 Issue Description:
> Domains controlling other domains are permitted to map pages owned by
> the domain being controlled. If the controlling domain unmaps such a
> page without flushing the TLB, and if soon after the domain being
> controlled transfers this page to another PV domain (via
> GNTTABOP_transfer or, indirectly, XENMEM_exchange), and that third
> domain uses the page as a page table, the controlling domain will have
> write access to a live page table until the applicable TLB entry is
> flushed or evicted. Note that the domain being controlled is
> necessarily HVM, while the controlling domain is PV.
More: https://xenbits.xen.org/xsa/advisory-217.html
XSA-218 Issue Description:
> We have discovered two bugs in the code unmapping grant references.
>
> * When a grant had been mapped twice by a backend domain, and then
> unmapped by two concurrent unmap calls, the frontend may be informed
> that the page had no further mappings when the first call completed rather
> than when the second call completed.
>
> * A race triggerable by an unprivileged guest could cause a grant
> maptrack entry for grants to be "freed" twice. The ultimate effect of
> this would be for maptrack entries for a single domain to be re-used.
More: https://xenbits.xen.org/xsa/advisory-218.html
XSA-219 Issue Description:
> When using shadow paging, writes to guest pagetables must be trapped and
> emulated, so the shadows can be suitably adjusted as well.
>
> When emulating the write, Xen maps the guests pagetable(s) to make the final
> adjustment and leave the guest's view of its state consistent.
>
> However, when mapping the frame, Xen drops the page reference before
> performing the write. This is a race window where the underlying frame can
> change ownership.
>
> One possible attack scenario is for the frame to change ownership and to be
> inserted into a PV guest's pagetables. At that point, the emulated write will
> be an unaudited modification to the PV pagetables whose value is under guest
> control.
More: https://xenbits.xen.org/xsa/advisory-219.html
XSA-220 Issue Description:
> Memory Protection Extensions (MPX) and Protection Key (PKU) are features in
> newer processors, whose state is intended to be per-thread and context
> switched along with all other XSAVE state.
>
> Xen's vCPU context switch code would save and restore the state only
> if the guest had set the relevant XSTATE enable bits. However,
> surprisingly, the use of these features is not dependent (PKU) or may
> not be dependent (MPX) on having the relevant XSTATE bits enabled.
>
> VMs which use MPX or PKU, and context switch the state manually rather
> than via XSAVE, will have the state leak between vCPUs (possibly,
> between vCPUs in different guests). This in turn corrupts state in
> the destination vCPU, and hence may lead to weakened protections
>
> Experimentally, MPX appears not to make any interaction with BND*
> state if BNDCFGS.EN is set but XCR0.BND{CSR,REGS} are clear. However,
> the SDM is not clear in this case; therefore MPX is included in this
> advisory as a precaution.
More: https://xenbits.xen.org/xsa/advisory-220.html
XSA-221 Issue Description:
> When polling event channels, in general arbitrary port numbers can be
> specified. Specifically, there is no requirement that a polled event
> channel ports has ever been created. When the code was generalised
> from an earlier implementation, introducing some intermediate
> pointers, a check should have been made that these intermediate
> pointers are non-NULL. However, that check was omitted.
More: https://xenbits.xen.org/xsa/advisory-221.html
XSA-222 Issue Description:
> Certain actions require removing pages from a guest's P2M
> (Physical-to-Machine) mapping. When large pages are in use to map
> guest pages in the 2nd-stage page tables, such a removal operation may
> incur a memory allocation (to replace a large mapping with individual
> smaller ones). If this allocation fails, these errors are ignored by
> the callers, which would then continue and (for example) free the
> referenced page for reuse. This leaves the guest with a mapping to a
> page it shouldn't have access to.
>
> The allocation involved comes from a separate pool of memory created
> when the domain is created; under normal operating conditions it never
> fails, but a malicious guest may be able to engineer situations where
> this pool is exhausted.
More: https://xenbits.xen.org/xsa/advisory-222.html
XSA-224 Issue Description:
> We have discovered a number of bugs in the code mapping and unmapping
> grant references.
>
> * If a grant is mapped with both the GNTMAP_device_map and
> GNTMAP_host_map flags, but unmapped only with host_map, the device_map
> portion remains but the page reference counts are lowered as though it
> had been removed. This bug can be leveraged cause a page's reference
> counts and type counts to fall to zero while retaining writeable
> mappings to the page.
>
> * Under some specific conditions, if a grant is mapped with both the
> GNTMAP_device_map and GNTMAP_host_map flags, the operation may not
> grab sufficient type counts. When the grant is then unmapped, the
> type count will be erroneously reduced. This bug can be leveraged
> cause a page's reference counts and type counts to fall to zero while
> retaining writeable mappings to the page.
>
> * When a grant reference is given to an MMIO region (as opposed to a
> normal guest page), if the grant is mapped with only the
> GNTMAP_device_map flag set, a mapping is created at host_addr anyway.
> This does *not* cause reference counts to change, but there will be no
> record of this mapping, so it will not be considered when reporting
> whether the grant is still in use.
More: https://xenbits.xen.org/xsa/advisory-224.html
Removing all `config.mpv.*` options will improve readability. MPV has many
configurable options, and using the config approach is prone to confusion and
unnecessary code duplication. If needed, the user can `override` the relevant
variables in the function itself, so no functionality is lost.
Closes issue #26786
Due to licensing costs, Vivaldi bundles a version of ffmpeg compiled
without support for the common H.264 codec. However, it is possible to
supply a custom libffmpeg.so with additional codecs. This derivation
uses the Chromium source to compile a compatible libffmpeg.so.
This approach is recommended by a Vivaldi developer, see
https://gist.github.com/ruario/bec42d156d30affef655
This allows users to specify a custom registry src,
because currently every packager would need to create
an outdated Cargo.lock just to be compatible with the
probably outdated rustRegistry in nixpkgs.
Currently there is no easy way to convince cargo to
do that, so this makes that workaround unnecessary.
Qt 5.8 is immediately removed because its support window is ended.
The qtlocation module is built with `enableParallelBuilding = false` so that the
clipper library will be built before the components which link to it.
kjs now depends directly on pcre. The dependency was previously propagated from
qtbase, which now depends on pcre2.
First of all, we need a newer version of Vc, because at least version
1.1.0 is required for Krita 3.1.3.
Also, qtmultimedia and qtx11extras were missing.
Built and tested successfully on my machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @abbradar
Packages get --host and --target by default, but can explicitly request
any subset to be passed as needed. See docs for more info.
rustc: Avoid hash breakage by using the old (ignored)
dontSetConfigureCross when not cross building
Includes a more recent version of antlr to nixpkgs. Previous
versions exist already, but version 4 brings many changes
to the generated code and runtime targets.
The install location has been changed from previous versions
of antlr to make use of the set-java-classpath hook, which
is required to make use of both the runtime and the binary.
Also includes the testing rig as a script to allow graphical
inspection of parse trees.
This change introduces a fixpoint, which allows to do deep override when
building packages defined in pkgs/development/beam-modules/default.hex.
This allows to provide beam.packages.erlang{,R16,R17,R18,R19} which
contains the same packages built with different Erlang/OTP versions.
Top-level attribute beamPackages points at beam.packages.erlangR18, the
same applies to other top-level Erlang packages.
TODO:
- beam.packages.erlang{R16,R17} is almost useless, since rebar/rebar3
does not build using these versions;
- all packages in beam.packages which use buildMix are actually built
with erlangR18;
- update documentation.
* ultrastardx-beta: init at 1.3.5
* libbass, libbass_fx: init at 24
* ultrastar-creator: init at 2017-04-12
* buildSupport/plugins.nix: add diffPlugins
Helper function to compare expected plugin lists to the found plugins.
* ultrastar-manager: init at 2017-05-24
The plugins are built in their own derivations, speeding up (re-)compilation.
The `diffPlugins` function from `beets` is reused to test for changes in the
plugin list on updates.
* beets: switch to diffPlugins
The function is basically just extracted for better reusability.
* Add kibana5 and logstash5
* Upgrade the elastic beats to 5.4
* Make sure all elastic products use the same version
(see elk5Version)
* Add a test for the ELK stack
Also updates beta, nightly, nightlyBin, and bootstrap compilers.
Also updates the registry.
Also consolidates logic between bootstrap and nightlyBin compilers.
Also contains some miscellaneous cleanups.
Also patches firefox to build with the newer cargo
Improvement: Use nix-shell for fetch.sh
androidsdk{,_extras}:
- Update to 7.1.1
google_apis_25 is missing after fetch.sh due to an error in addon.xml
(upsteam bug).
Addons:
- Add google_apis_25
- Update google_play_services (v8_rc41 -> v11_rc16)
lxappearance supports both Gtk+-2 and Gtk+-3. The current `lxappearance'
package continues to be for Gtk+-2. Add `lxappearance-gtk3' for Gtk+-3.
A patch is needed in order to look for themes in system data dirs with
Gtk+-3.
* firefox-beta-bin: 51.0b8 -> 54.0b13
* firefox-devedition-bin: init at 54.0b14
Firefox DevEdition became a new product of Mozilla and is "repackaged"
Firefox Beta with its own release channel and six weeks release cycle as
other channels. It is no longer being built on nightly basis
* updated the update.nix script to facilitata firefox-devedition-bin
* disabling automatic updates by pointing to non existing channel
* f firefoxWrapper looks for gtk3 attribute to wrap the executable gtk3 to wrap the binary with needed ``XDG_DATA_DIRS``
This applies to Erlang, Elixir and LFE packages.
beam-packages provides interpreters and packages sets separately. This
is in preparation of generalizing BEAM interpreters definitions.
Move most of wine configurations to winePackages which is not built on Hydra.
Leave two top-level packages:
wine: stable release with an "office" configuration;
wineStaging: staging release with a "full" configuration.
* dkimproxy: init at 1.4.1
* dkimproxy: simplify by using mkDerivation
* dkimproxy: set ekleog as maintainer
* dkimproxy: style fix
* dkimproxy: also work without the right PERL5LIB environment variable
This still causes some uncached rebuilds, but master(!) and staging
move too fast forward rebuild-wise, so Hydra might never catch up.
(There are also other occasional problems.)
Therefore I merge at this point where the rebuild isn't that bad.
Since they are executables they should be at top-level.
We build statically to shorten invocation time (at the moment haskell packages
have the problem of too large RPATHs).
- `isGNU` to `isHurd`, my sedding did not catch
- Simplify cross compilation in general
- Be more careful about python
- no more `gdbCross` in all-packages
This is especially useful when not cross compiling. It means we can
remove the `stdenv.isGlibc` predicate too.
Additionally, use this to simplify the logic to choose the
appropriate libiconv derivation.
* google-app-engine-go-sdk: init at 1.9.53
* google-app-engine-go-sdk: simplify python wrapper, use fetchzip
* add myself to maintainer list
* google-app-engine-go-sdk: add lufia as maintainer
git series tracks changes to a patch series over time. git series also
tracks a cover letter for the patch series, formats the series for
email, and prepares pull requests.
https://github.com/git-series/git-series
