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

bug: HM backups its own generated files #5726

Closed
2 tasks done
Libadoxon opened this issue Aug 12, 2024 · 7 comments
Closed
2 tasks done

bug: HM backups its own generated files #5726

Libadoxon opened this issue Aug 12, 2024 · 7 comments
Assignees
Labels
bug triage Issues or feature request that have not been triaged yet

Comments

@Libadoxon
Copy link

Are you following the right branch?

  • My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

  • I have searched the existing issues

Issue description

I'm using the home-manager firefox module and defined some custom search engines like so:

Config Snippet
  programs.firefox.profiles.<name>.search = {
    default = "startpage";
    privateDefault = "startpage";
    engines = {
      startpage = {
        id = "startpage@nixos";
        urls = [
          {
            template = "https://www.startpage.com/do/search?prfe=e48b2e857307fd3c8072f11ae90083fcc78ab18567a5d00b50dfaed8f9a2b466eb09282fff5fb1bd0adb8040720e12b4f058c54302528ca52d20b7c08b2d5d66a86f205976ef4a656670b7b2";
            params = [
              {
                name = "query";
                value = "{searchTerms}";
              }
            ];
          }
        ];

        definedAliases = [
          "@startpage"
          "@st"
        ];
      };
      "Nix Packages" = {
        id = "np@nixos";
        urls = [
          {
            template = "https://search.nixos.org/packages";
            params = [
              {
                name = "type";
                value = "packages";
              }
              {
                name = "channel";
                value = "unstable";
              }
              {
                name = "query";
                value = "{searchTerms}";
              }
            ];
          }
        ];

        icon = "${pkgs.nixos-icons}/share/icons/hicolor/scalable/apps/nix-snowflake.svg";
        definedAliases = [ "@np" ];
      };
      "NixOs Options" = {
        id = "no@nixos";
        urls = [
          {
            template = "https://search.nixos.org/options";
            params = [
              {
                name = "channel";
                value = "unstable";
              }
              {
                name = "query";
                value = "{searchTerms}";
              }
            ];
          }
        ];

        icon = "${pkgs.nixos-icons}/share/icons/hicolor/scalable/apps/nix-snowflake.svg";
        definedAliases = [ "@no" ];
      };
      "HM Options" = {
        id = "hm@nixos";
        urls = [
          {
            template = "https://home-manager-options.extranix.com";
            params = [
              {
                name = "release";
                value = "master";
              }
              {
                name = "query";
                value = "{searchTerms}";
              }
            ];
          }
        ];

        definedAliases = [ "@hm" ];
      };
      "Noogle" = {
        id = "nog@nixos";
        urls = [
          {
            template = "https://noogle.dev/q";
            params = [
              {
                name = "term";
                value = "{searchTerms}";
              }
            ];
          }
        ];

        definedAliases = [ "@nog" ];
      };
    };
  };

Now I'm facing an issue where sometimes (ca. 40%) when I rebuild home-manager backups a file named search.json.mozlz4 in ~/.mozilla/firefox/<profile-name>. This file was generated by home-manager so I'm not sure why it does that. But when comparing the two files they are identical, so I'm wondering why home-manager even tries to create a backup.

This gets really annoying as I have to delete this file on a regular basis.

Maintainer CC

No response

System information

- system: `"x86_64-linux"`
 - host os: `Linux 6.6.44, NixOS, 24.11 (Vicuna), 24.11.20240804.cb9a96f`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.5`
 - nixpkgs: `/nix/store/4cpakzyvfw1rmm9v5i3387x6jd2h1v86-source`
@Libadoxon Libadoxon added bug triage Issues or feature request that have not been triaged yet labels Aug 12, 2024
@Libadoxon
Copy link
Author

Pinging @rycee, @kira-bruneau and @brckd as this seems to be a problem with the firefox module.

@brckd
Copy link
Contributor

brckd commented Aug 19, 2024

search.json.mozlz4 is hashed using mozlz4 (as the file name suggests). Therefore it's plausible that the resulting file changes for no apparent reason, even though the config remains the same. There might be nothing we can do about this.

But why you often need to delete this file? This shouldn't be necessary with nix.

@brckd
Copy link
Contributor

brckd commented Aug 19, 2024

@Libadoxon
Copy link
Author

Well because hm backs it up and then complains, that there is a collision. But, as mentioned above, the backup and the newly generated file do not differ so I don't know why the backup is made in the first place.

@brckd
Copy link
Contributor

brckd commented Aug 20, 2024

As I tried to explain, the content of the file doesn't change, but the way it's encoded does. HM replaces the file because its bytes differ from the previous file due to the encoding.

I'm as clueless as you as to what causes it to encode differently, but I can check when I'm back from vacation. A possible fix would be to only generate the file when the config is changed, but I don't know whether that's possible.

In the meantime, check out this comment which shows how to replace the file unconditionally.

It should look something like this:

home.file.".mozilla/firefox/<profile-name>/search.json.mozlz4".force = true

@kira-bruneau
Copy link
Contributor

kira-bruneau commented Aug 20, 2024

Oh yep this is a duplicate of #3698. It sounds like you need to use the force option like @brckd mentioned.

This is pretty easy to forget though and isn't that discoverable if you don't look through the docs. I was planning on refactoring the search submodule to require an enable option instead of force: #5697 (comment), but I was still waiting on that first PR to be merged.

@Libadoxon
Copy link
Author

okay closing then

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug triage Issues or feature request that have not been triaged yet
Projects
None yet
Development

No branches or pull requests

6 participants