libreoffice-unwrapped points to the same libreoffice than libreoffice.
libreoffice-*-unwrapped exists for all versions
This bring an incompatible change where a user using
`libreoffice-unwrapped` hoping to use `fresh` would now be inadvertently
be using `still`.
The previous description "string" is misleading in the full options
manual pages; they are actually concatenated strings, with a specific
character.
The empty string version ("types.string") has been special-cased to
provide a better message.
The previous tentative to the fix got the order mixed up a bit. This
new fix has been re-verified to get them in the good order as per the
instructions in the following chapters.
The tests in <nixos/tests/installer.nix> are using `parted`, so they are
bound to be better tested than `fdisk`.
This is brought on by a couple issues, plus reports on IRC that the
`fdisk` instructions didn't work as expected.
* #39354
* #46309
* #39942
* #45478
Care was taken so that the other documented steps did not need changes.
In all this kerfufle, a slight re-organization of the Chapter has been
made, allowing better deep linking.
While it seemingly brings more attention to the macOS notes with the
default docbook template, it better represents which parts of the
section are about macOS, and which parts are simply in the flow of the
text; otherwise the last paragraph may be lost into the details for
macOS.
This seems like a known issue as other distributions (ArchLinux here)
have patches fixing the issue.
This hopefully fixes more than one dependant builds for ZHF 18.09.
b785d4813e introduced breakage in Qt
modules for 5.6 and 5.9, especially visible is Qt Webkit.
This was manifested by having a non-sensical build log where it is using
the top-level `src` attribute as source instead of Qt Webkit's own
source.
Were it not for the `src` top-level attribute (which is a legit
package), the error would have been made obvious by passing `null` to
`src`.
This partily reverts newly introduced way `src` can be passed to a
qtModule, instead relying on extending the `srcs` attrset.
For ZHF #45960
This is the semantics as understood by `xdg-open`. Using these semantics
on a non-colon-separated variable works because it acts as if it was a
one element long list.
This fixes an issue where it would try to exec
`google-chrome-beta:google-chrome:chromium:firefox` on a system
configured with these semantics in mind.
The background color option is self-explanatory.
The mode is either `normal` or `stretch`, they are as defined by GRUB,
where normal will put the image in the top-left corner of the menu, and
stretch is the default, where it stretches the image without
consideration for the aspect ratio.
* https://www.gnu.org/software/grub/manual/grub/grub.html#background_005fimage
The wallpaper used is *structurally compatible* with the other one,
meaning that the logo is at the same location, and not bigger.
It has one drawback: the logo is brighter, which clashes with the grub
usage. This is to be fixed with new options in grub.
This is a 277K (as of right now) addition that can greatly help in some
last recourse scenarios. The specific rEFInd setup will not be able to
boot the installer image, but this is not why it has been added. It has
been added to make use of its volumes scanning capabilities to boot
existing EFI images on the target computer, which is sometimes necessary
with buggy EFI. While is isn't NixOS's job to fix buggy EFI, shipping
this small bit with the installer will help the unlucky few.
Example scenario: two wildly different EFI implementation I have
encountered have fatal flaws in which they sometimes will lose all the
settings, this includes boot configuration. This is compounded by the
fact that the two specific and distinct implementation do not allow
manually adding ESP paths from their interface. The only recourse is to
let the EFI boot the default paths, EFI/boot/boot{platform}.efi, which
is not a default location used by the NixOS bootloaders. rEFInd is able
to scan the volumes and detect the existing efi bootloaders, and boot
them successfully.
I'm not sure of the semantics of `gcc` vs. `ld` for linking, but it
makes the difference between working and:
```
/nix/store/gpc2wld1s0c6qzx9326cwn1wcx29xzsj-binutils-2.30/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000401100
```
This allows a developer to better identify in which snippet the
failure happened. Furthermore, users seeking help will have more
information available about the failure.
Samuel Dionne-Riel