When home-manager manages the Firefox configuration, the `profiles.ini`
file in `~/.mozilla/firefox/` is immutable. Any attempt by Firefox to
update it fails accordingly. Currently, when multiple profiles are defined,
it is not possible to choose a non-default one by passing a `-Profile`
option to Firefox, or by using `firefox -ProfileManager`: if the user
chooses a non-default profile, Firefox tries to update the `profile.ini`
with this choice, which fails because of the file's immutability, and
Firefox refuses to start up. The user is shown an error saying `An
unexpected error has prevented your changes from being saved.`.
Currently, the setting to save the profile choice back to `profiles.ini` is
hardcoded in home-manager. This Pull Request changes that, so the file is
never updated with the user choice.
This fixes the cases where a user attempts to start a non-default profile.
I think this is also matches home-manager philosophy nicely: because we
define what the default profile is in our home-manager config, the user
should not be able to change that in the firefox gui, because then the
active configuration would diverge from what's defined in home-manager.
As a matter of fact, the user currently can't change the default anyway,
as trying to do so results in an error, but the user should be able to
choose a profile for an individual Firefox instance.
The Firefox Profile Manager GUI (that you get by starting Firefox with the
`-ProfileManager` option) has a check box to decide whether to "use the
selected profile without asking at startup", i.e. make it the new default.
This is currently ticked (because it's hardcoded in home-manager as
`StartWithLastProfile = 1`). If it stays ticked, choosing any profile other
than the default results in the error. Unticking this box will also not
help, because now Firefox would attempt to update `profiles.ini` with
`StartWithLastProfile=0`.
Either way, when home-manager manages the Firefox config for us, we cannot
have Firefox update `profiles.ini`, and therefore we cannot change the
default profile through Firefox's GUI.
With this fix, choosing a different profile on the command line (`firefox
-Profile foo`) or via the GUI (`firefox -ProfileManager`) now works. The
user will still get an error when they tick the checkbox to "use the
selected profile without asking at startup", because that results in an
attempt to update `profiles.ini`. Also, it would mean that the chosen
default profile would diverge from the setting in the user's home-manager
config - so not allowing this seems sensible.
When the user changes which addresses mu should consider 'personal',
mu's store should be reinitialized.
After this change, the activation script parses the previously
configured list of addresses and compares it with the new one. If they
differ, it runs the init command even when the store has already been
initialized.
Currently translated at 100.0% (37 of 37 strings)
Co-authored-by: David Chocholatý <chocholaty.david0@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/home-manager/cli/cs/
Translation: Home Manager/Home Manager CLI
Else I get a
===
… while calling the 'throw' builtin
at /nix/store/afpmddfrmx5df3h16bdh00yy8i7db8w4-source/pkgs/desktops/gnome/default.nix:96:28:
95| gnome-shell = throw "The ‘gnome.gnome-shell’ was moved to top-level. Please use ‘pkgs.gnome-shell’ directly."; # Added on 2024-08-28.
96| gnome-shell-extensions = throw "The ‘gnome.gnome-shell-extensions’ was moved to top-level. Please use ‘pkgs.gnome-shell-extensions’ directly."; # Added on 2024-08-11.
| ^
97| gnome-software = throw "The ‘gnome.gnome-software’ was moved to top-level. Please use ‘pkgs.gnome-software’ directly."; # Added on 2024-08-11.
error: The ‘gnome.gnome-shell-extensions’ was moved to top-level. Please use ‘pkgs.gnome-shell-extensions’ directly.
===
on rebuild
The home manager script fails when $USER contains special characters.
For example, my work PC is managed by company's LDAP and username is <COMPANY>\<user>). When running home-manager switch I get the following error:
```
error: flake 'path:/home/<COMPANY>/<user>/.config/home-manager' does not provide attribute 'packages.x86_64-linux.homeConfigurations."<COMPANY>\<user>".activationPackage', 'legacyPackages.x86_64-linux.homeConfigurations."<COMPANY>\<user>".activationPackage' or 'homeConfigurations."<COMPANY>\<user>".activationPackage'
Did you mean <COMPANY><user>?
```
There are two types of strings that need escaping:
strings in Nix expressions (e.g. home.nix generated by home-manager init)
they need backslashes before special chars
flake URI (passed to nix build)
they need URI's percent encoding, luckily jq supports that
Previously, only the main identity of an account would get the proper SMTP
server assigned. Identities corresponding to aliases would not get an SMTP
server assigned at all, leading to a (Thunderbird-internal) fallback to the
SMTP server associated to the primary account. This is obviously wrong for
non-primary accounts having aliases associated to them. Fix it by specifying
the SMTP server explicitly for all identities.
* mbsync: Add NEWS entry about isync 1.5.0 changes
* mbsync: Place config file in $XDG_CONFIG_HOME
mbsync 1.5.0 supports placing isync's configuration file in
$XDG_CONFIG_HOME/isyncrc [1].
[1] https://sourceforge.net/projects/isync/files/isync/1.5.0/
* mbsync: Replace SSLType with TLSType
mbsync 1.5.0 replaced the name of the configuration option [1].
Also update SSLVersions to TLSVersions for the same reason. Inform the
user if the option was renamed.
[1] https://sourceforge.net/projects/isync/files/isync/1.5.0/
* mbsync: Replace SSLVersions with TLSVerisons
* mbsync: Update extraConfig.account example with SSL->TLS changes
Some fish plugins such as https://github.com/acomagu/fish-async-prompt
require that starship be initialized as non-interactive.
When the `programs.starship.enableInteractive` option is enabled,
starship is initialized at the end of the init script, outside the
interactive block.
Now accepts an empty list, which turns off the code so the user can
manually set ZSH_AUTOSUGGEST_STRATEGY anywhere they want via any of the
`*Variables` module options.
The initExtra code is executed after systemd graphical-session.target
starts, which means graphical applications started by
graphical-session.target cannot get these X settings.
The initExtra code is executed after systemd graphical-session.target
starts, which means graphical applications started by
graphical-session.target cannot get these X settings.