Functional again as of now if services.gvfs.enable = true; is set. gvfs is not required anymore.

Not ready yet because still alpha software.

Worked with the dev a bit to iron out some issues that seemed nixos-specific, and they released 0.1.0. I'll open it for review so this can get some eyes onto it. It still contains a couple hacks though.

Some initial nits:

• Use tag over rev since we now have tagged releases
• nativeBuildInputs should go before buildInputs

diff --git a/pkgs/by-name/ba/bazaar/package.nix b/pkgs/by-name/ba/bazaar/package.nix
index c9d0c11bc8b7..dae59029c219 100644
--- a/pkgs/by-name/ba/bazaar/package.nix
+++ b/pkgs/by-name/ba/bazaar/package.nix
@@ -64,10 +64,18 @@ stdenv.mkDerivation (finalAttrs: {
   src = fetchFromGitHub {
     owner = "kolunmi";
     repo = "bazaar";
-    rev = "v${finalAttrs.version}";
+    tag = "v${finalAttrs.version}";
     hash = "sha256-QzzWj6KjyKNMBHQ/RqvUSL6QeokgvK2Fc+23kkt3SMM=";
   };
 
+  nativeBuildInputs = [
+    desktop-file-utils
+    meson
+    ninja
+    pkg-config
+    wrapGAppsHook4
+  ];
+
   buildInputs = [
     appstream
     flatpak
@@ -88,14 +96,6 @@ stdenv.mkDerivation (finalAttrs: {
     libyaml
   ];
 
-  nativeBuildInputs = [
-    desktop-file-utils
-    meson
-    ninja
-    pkg-config
-    wrapGAppsHook4
-  ];
-
   mesonFlags = [
     (lib.mesonOption "hardcoded_content_config_path" "${finalAttrs.passthru.configFile}")
   ];

Is the patch we have currently able to be upstreamed/fixed in Bazaar proper or is it a Nix specific thing that wouldn't make sense to do so?

never mind the patch is for libglycin

and show a placeholder like "there's nothing here" in the curated section.

From a design perspective it should either be absent/not visible (ideal) or they would be a specific message saying that there is no configuration/curation provided (less ideal).

Re: my comment about branding: I don't have an idea of what Nix branding might look like since NixOS is a general purpose DIY distribution. There could maybe exist a general purpose configuration upstream that can just be used if the distribution doesn't wish to curate anything specific because it looks like the config takes hardcoded flatpak refs instead of being sorted by tags.

I remember seeing mockups for a trending page in the GNOME design matrix but I don't see that there from your screenshot.

To be perfectly clear, this is what the "curated" page looks like when no config is set:

The wording seems to imply that this is not how it should be and unexpected by bazaar. I have no idea how to resolve this, because I don't think it's a good idea to just "put something there" because it might not be relevant at all to our users. This model only really works for the uBlue folks, because they are all about that curated/omakase experience.

I've drafted a upstream issue for this to see what approach we should take.

Had to update libdex also. PR search is broken for me right now, so for testing purposes in the same PR.

suggestion: remove libdex commit

The libdex version bump no longer needs to be included, most apps aren't using this new of a libdex version as it isn't in the GNOME 48 SDK kolunmi/bazaar@2e243a5

thought: Curated section issue resolved

This issue was resolved in kolunmi/bazaar@f19feae so we don't have to worry about a default configuration in the next major version.

Alright I think I can do that if I up the package to 0.3.1.

Nope, I still get Dependency libdex-1 found: NO. Found 0.10.1 but need: '>= 0.11.1'.

That change seems to have been reverted in https://github.com/kolunmi/bazaar/commits/a7504afb8fbe960577346e9ea55b5bed227003b7

I guess we're waiting for an upstream change like kolunmi/bazaar#214 ? Or do I just override the src and version for libdex in pkgs/by-name/ba/bazaar/package.nix?

Image loading still broken......