NixOS Packaging #204
Comments
|
I managed to fix the issue by copying |
|
I got this when trying to launch a web app: |
|
Path In case modifying global For native messaging manifest, if there is no automatic way of installing it to the required location, displaying instructions how to create a symlink to the manifest after installing the package (as it's done for Homebrew) is enough. |
|
I made some progress on this. # <https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=firefox-pwa>
{
stdenv,
rustPlatform,
fetchFromGitHub,
openssl,
pkg-config,
maintainers,
}: let
version = "2.1.2";
source = fetchFromGitHub {
owner = "filips123";
repo = "PWAsForFirefox";
rev = "v${version}";
sha256 = "sha256-zJSrZOLHyvvu+HoHrPkDDISuY9GqpKtwGn/7jKzg5pI=";
};
in
rustPlatform.buildRustPackage {
pname = "firefox-pwa";
inherit version;
src = "${source}/native";
cargoSha256 = "sha256-zLl7WvGzN/ltc7hT5cAsp3ByrlThQmRXrGM5rKbntdY=";
doCheck = false;
nativeBuildInputs = [pkg-config];
buildInputs = [openssl.dev openssl];
preConfigure = ''
# replace the version number in the manifest
sed -i 's;version = "0.0.0";version = "${version}";' Cargo.toml
# replace the version in the lockfile, otherwise Nix complains
sed -zi 's;name = "firefoxpwa"\nversion = "0.0.0";name = "firefoxpwa"\nversion = "2.1.2";' Cargo.lock
# replace the version number in the profile template files
sed -i $'s;DISTRIBUTION_VERSION = \'0.0.0\';DISTRIBUTION_VERSION = \'${version}\';' userchrome/profile/chrome/pwa/chrome.jsm
'';
installPhase = let
target = "target/${stdenv.targetPlatform.config}/release";
in ''
runHook preInstall
# Executables
install -Dm755 ${target}/firefoxpwa $out/bin/firefoxpwa
install -Dm755 ${target}/firefoxpwa-connector $out/lib/firefoxpwa/firefoxpwa-connector
# Manifest
install -Dm644 manifests/linux.json $out/lib/mozilla/native-messaging-hosts/firefoxpwa.json
sed -i "s;/usr/libexec/firefoxpwa-connector;$out/lib/firefoxpwa/firefoxpwa-connector;" $out/lib/mozilla/native-messaging-hosts/firefoxpwa.json
# Completions
install -Dm755 ${target}/completions/firefoxpwa.bash $out/share/bash-completion/completions/firefoxpwa
install -Dm755 ${target}/completions/firefoxpwa.fish $out/share/fish/vendor_completions.d/firefoxpwa.fish
install -Dm755 ${target}/completions/_firefoxpwa $out/share/zsh/vendor-completions/_firefoxpwa
# Documentation
install -Dm644 ${source}/README.md $out/share/doc/firefoxpwa/README.md
install -Dm644 README.md $out/share/doc/firefoxpwa/README-NATIVE.md
install -Dm644 ${source}/extension/README.md $out/share/doc/firefoxpwa/README-EXTENSION.md
install -Dm644 packages/deb/copyright $out/share/doc/firefoxpwa/copyright
# UserChrome
mkdir -p $out/share/firefoxpwa/userchrome/
cp -r userchrome/* $out/share/firefoxpwa/userchrome/
runHook postInstall
'';
}{self, ...}: {
config,
lib,
pkgs,
...
}: let
inherit (lib) types;
cfg = config.programs.firefox.pwa;
in {
options = {
programs.firefox.pwa = {
enable = lib.mkEnableOption (lib.mdDoc "enable");
package = lib.mkOption {
type = types.package;
default = pkgs.firefox-pwa;
description = lib.mdDoc '''';
example = lib.literalExpression '''';
};
executables = lib.mkOption {
type = types.path;
readOnly = true;
default = "${cfg.package}/bin";
description = lib.mdDoc '''';
example = lib.literalExpression '''';
};
sysData = lib.mkOption {
type = types.path;
readOnly = true;
default = "${cfg.package}/share";
description = lib.mdDoc '''';
example = lib.literalExpression '''';
};
userData = lib.mkOption {
type = types.path;
default = "${config.xdg.dataHome}/firefoxpwa";
description = lib.mdDoc '''';
example = lib.literalExpression '''';
};
};
};
config = lib.mkIf cfg.enable {
home.sessionVariables = {
FFPWA_EXECUTABLES = cfg.executables;
FFPWA_SYSDATA = cfg.sysData;
FFPWA_USERDATA = cfg.userData;
};
home.file.".mozilla/native-messaging-hosts/firefoxpwa.json".source = "${cfg.package}/lib/mozilla/native-messaging-hosts/firefoxpwa.json";
home.packages = [
(cfg.package.overrideAttrs (_: {
postInstall = ''
ln -s $out/lib/firefoxpwa/firefoxpwa-connector $out/bin;
'';
}))
];
};
}Now, the extension recognizes the binaries and the native messaging description. I can create profiles and add PWAs from the extension popup. I face an issue where the extension assumes the path of When I launch from the |
|
Showing recent changes: Home Manager module: programs.firefox.package = cfg.firefoxPackage.overrideAttrs (old: {
nativeBuildInputs = old.nativeBuildInputs ++ [pkgs.makeWrapper];
postFixup = ''
wrapProgram ${lib.getExe cfg.firefoxPackage} \
--set FFPWA_EXECUTABLES '${cfg.executables}' \
--set FFPWA_SYSDATA '${cfg.sysData}' \
--set FFPWA_USERDATA '${cfg.userData}'
'';
});Debugging: $ firefoxpwa runtime install
07:34:24 [WARN] This will download the unmodified Mozilla Firefox and locally modify it
07:34:24 [WARN] Firefox is licensed under the Mozilla Public License 2.0
07:34:24 [WARN] Firefox is a trademark of the Mozilla Foundation in the U.S. and other countries
07:34:24 [WARN] This project is not affiliated with the Mozilla Foundation in any way
07:34:24 [WARN] By using this project you also agree to the Firefox Privacy Notice: https://www.mozilla.org/privacy/firefox/
07:34:24 [WARN] Check the Firefox website for more details: https://www.mozilla.org/firefox/
07:34:24 [INFO] Downloading the runtime archive
07:54:28 [INFO] Extracting the runtime archive
07:54:37 [INFO] Copying the runtime
07:54:37 [INFO] Runtime installed!$ firefoxpwa site launch 01GJF97WY5Q6P74R5J2JRZARFV
07:54:55 [INFO] Patching the runtime
07:54:55 [INFO] Runtime patched!
07:54:55 [INFO] Patching the profile
07:54:55 [INFO] Profile patched!
07:54:55 [INFO] Launching the web app
07:54:55 [ERROR] No such file or directory (os error 2)What exactly is not found? $ echo $FFPWA_EXECUTABLES && ls $FFPWA_EXECUTABLES
/nix/store/zf1mqcdpcb4d2ga54wjpv8mygzxfw03p-firefox-pwa-2.1.2/bin
firefoxpwa firefoxpwa-connector
$ echo $FFPWA_SYSDATA && ls $FFPWA_SYSDATA
/nix/store/zf1mqcdpcb4d2ga54wjpv8mygzxfw03p-firefox-pwa-2.1.2/share/firefoxpwa
userchrome
$ echo $FFPWA_USERDATA && ls $FFPWA_USERDATA
/home/jacob/.local/share/firefoxpwa
config.json firefoxpwa.log profiles runtimeAlso, in previous messages the code shown does not include |
|
It looks like the site launch failed when trying to launch |
|
Here is my attempt: https://github.com/pasqui23/nixpkgs/blob/firefox-pwa/pkgs/tools/networking/firefox-pwa/default.nix However if I try to open a PWA I get the error: |
|
@pasqui23 It's a bad idea to use Why did you use After line 47, where |
|
On 10/02/23 02:16, Jacob Birkett ***@***.***> wrote:
@pasqui23 <https://github.com/pasqui23> It's a bad idea to use |~| in
package derivations, I don't even think Nixpkgs would accept it. Could
be wrong.
I was trying to fix the error `Failed to patch the runtime: Path "/usr/share/userchrome/runtime" does not exist or you don't have access!` and found that `FFPWA_SYSDATA` is read at build time, not runtime. I thought that if it pointed to inside the home directory then it would have higher chance to have write permissions to the path but I was wrong. This is absolutely not ready for pr and in fact I wanted to ask the author for suggestions.
Why did you use |postInstall| rather than |installPhase|? In this case,
the behavior is 100% custom and therefore should /override/ the default
from |buildRustPlatform|, unless I'm mistaken and we still need that
default phase.
After line 47, where |wrapArgs| is defined; are you sure you don't want
to use |${wrapArgs[@]}| in usages?
I'll take those in consideration *after* I managed to made it work.
|
This error is probably caused because UserChrome stuff hasn't been copied to the correct location. I think the problem is that you have set PWAsForFirefox expects
It should be read both at build and runtime. |
|
@filips123 |
That is incredibly useful to know. Will try exposing the var at build time and getting back to people @ here. |
|
@filips123 How I make use of this information depends on: |
|
Looks like it is either-or. PWAsForFirefox/native/src/directories.rs Line 63 in 014b1a4 |
|
What does "on windows" mean? Is it PWAsForFirefox/native/src/directories.rs Line 36 in 014b1a4 |
It's because
It just sets the location of the system data directory to the value of Basically, directories are set in this way:
Then I think Here is a rough overview of how I think the package should be set up to work:
|
|
@filips123 I don't think that you can have unversioned paths for the executables, because everytime nix builds a package it stores it with a hash in the path. Would links work? Because it is possible to do something like |
|
Links should probably work. The reason why it needs unversioned paths or something similar is that generated
Also, after checking some thing a bit, |
Again I've already tried to do |
|
Not worried about any of that, already got all of the paths set up how you've described. I only asked for clarification because of the wording of one of @filips123's comments and quickly resolved by looking at @filips123 Would it be possible for you to publish your two (or three?) Git-vendored crates on crates.io? They are quite difficult to get working with Nix because something something hashing something something. |
|
@pasqui23 I think the problem is that I've said @spikespaz Well, |
|
@filips123 Mind making them submodules? I totally understand if you don't want to, I get that submodules aren't always the easiest for you, and you've gotta keep them up to date before the lock file. Probably really annoying. |
|
Yeah, submodules can be quite annoying... Is there some other way of creating Nix packages with crates from Git? I don't know how useful that is, but you can still obtain commit hashes for Git dependencies in |
|
@filips123 Nix is dumb strict about hashes for everything. It isn't satisfied by commit hashes. I've argued about it before. I'll look deeper tomorrow, I don't even want you to deal with submodules. I'll find some sort of hack, or maybe extract one of the release |
|
Thanks! I think it would still be nice if the package can get into nixpkgs, so if you cannot find any other way that is accepted, I can still publish |
Note that the |
|
Someone's actually on it @theLockesmith, you can follow the packaging effort here: NixOS/nixpkgs#263404 |
|
Three of us, perhaps more, have tried. Why don't we just modify the project itself to allow for vendored Firefox to be provided, and disable the downloading feature? |
|
Well, it already allows using Firefox without downloading. It just needs to be copied/symlinked into the correct location, which is |
|
Is the output of |
|
And perhaps, a feature gate which disables downloading altogether, and instead showing an error when it decides that something should be downloaded and isn't already present. |
|
On 11/12/23 23:57, Jacob Birkett ***@***.***> wrote:
Is the output of |nix build 'nixpkgs#firefox'| suitable to be linked to
that location?
For reference, said output is a directory with inside a bin directory, witch itself contains the firefox binary. It also should have all kind of necessary files in a structure resembling /usr on more traditional distros
|
|
Actually, I think symlink to system files won't work, because some files in that directory need to be modified/added (specifically, Other options instead of symlinking the whole directory could be symlinking just specific files (#403) or using FUSE OverlayFS (#67, #214), but none of these options are quite ready yet... In any case, the target directory should have the same structure as the one from official Firefox tarballs. Additionally, it should be possible for user to switch that default provided Firefox with another Firefox version/fork. Adding an option to disable downloading at compile time is also possible. However, I don't really know why downloading Firefox like it's currently done is a problem... Is it the problem that the downloaded Firefox won't work correctly because it needs some NixOS-specific configuration, or something else? |
|
The problem is that almost every program needs to be patched, in some way, for some reason, with us NixOS users. Your follow-up has confirmed my skepticism, and validated my memory as to why I stopped working on this. What could work is doing the patching (all of it, yours and ours) at build time. Is there a way to run your tool on a given directory that contains Firefox files? If we can call a program to do these patches for FFPWA we could just link that instead after building all of the binaries. |
So, the program would apply all FFPWA changes to Firefox in a given directory? This is currently not possible, but I think it should be possible to add a command that does something like this (something like I'm not that familiar with NixOS, so I have a few more questions. Currently, the runtime is stored along with user data in a user-specific directory, which means the runtime needs to be duplicated for each user. I don't know how NixOS handles users, so is this fine? Otherwise, I think it should also be possible to create a build-time option to change the runtime directory to a global location. How will updates to Firefox and FFPWA be handled in this case? When Firefox is updated, the latest Firefox version needs to be copied into that directory and FFPWA patches need to be applied. Similarly, when FFPWA is updated, the new patches also need to be applied. |
|
NixOS' big problem is that it doesn't install anything in Firefox as packaged by nixpkgs instead will load the necessary libraries each from their specific directories in Firefoxpwa as packaged in nixpkgs work around this by being started in a user namespace where libc is present in |
This would be perfect. If we can give it a path to a Firefox distribution, for example {
programs.firefpx-pwa.firefoxPackage = pkgs.firefox;
programs.firefox-pwa.firefoxPackagePatched = let
super = config.programs.firefox-pwa.firefoxPackage;
in
pkgs.symlinkJoin {
pname = super.pname + "-ffpwa-patched";
inherit (super) version meta;
paths = [ super ];
nativeBuildInputs = [ config.programs.firefox-pwa.package ];
postInstall = ''
firefoxpwa runtime patch .
'';
};
}This code (untested, typed in GitHub) should just take the existing Firefox package (set by
I know this might seem wrong, but we would disable automatic updates. This isn't something I like as a NixOS user. Everything will update when I tell it to, by running I think the best way to do this would be to have a Cargo feature,
If I recall, this is Is there anything inside of |
I meant if the user only updates the Firefox package but not PWAsForFirefox, is it possible to automatically re-apply PWAsForFirefox modifications to that new Firefox version (and opposite if the user only updates PWAsForFirefox package but not Firefox package). (I don't know if updating only specific packages is possible on Nix.)
Yeah, this should be possible.
It uses
Currently, runtime is stored in However, I can also add another environment variable like Also, what is that user namespace that @pasqui23 mentioned? |
I was sightly mistaken, firefoxpwa as packaged by @camillemndn uses LD_LIBRARY_PATH and GTK_PATH directly to find the correct libraries, no user namespaces needed. Otherwise, nixpkgs includes a framework to use bubblewrap to run a binary in a root directory mirroring a standard LFS root. |
|
So, what's the difference between using NixOS-provided immutable runtime and using |
|
On 23/12/23 11:52, Filip Š ***@***.***> wrote:
So, what's the difference between using NixOS-provided immutable runtime
and using |LD_LIBRARY_PATH| and |GTK_PATH| or user namespaces with
"normal" downloaded runtime? I guess immutable runtime is the "intended"
way of doing things, but are there other differences? Do these two
different options affect performance, usability, etc.?
Actually the environment variables way is the idomatic way, as using the user namespace wrapper incours a slight performance penalty and adds a dependency on a linux kernel with user namespaces enabled.
|
|
https://github.com/Rutherther/nur-pkgs/tree/master/pkgs/firefoxpwa found it packaged by someone in NUR, but outdated (2.7.3), would it be possible to get it working based on this? I managed to get it installed and was able to get through connector recognition phase and even runtime installation, but wasn't able to actually run a PWA that I successfully installed according to the extension, just wasn't starting up (microsoft teams in my case), but I'm not sure if it's because it's outdated or because something else there is broken Here's minimal working config (using HM): home.packages = with pkgs; [
nur.repos.rutherther.firefoxpwa
];
programs.firefox = {
enable = true;
package = pkgs.firefox.override {
nativeMessagingHosts = with pkgs; [
nur.repos.rutherther.firefoxpwa-unwrapped
];
};
};I really like firefox (or floorp, override also works there btw, started using it recently, cuz after using Vivaldi, can't live without sidebar, but I really prefer firefox with it's performance and degree of additional customizability I can get with extensions) and the only thing that keeps me from using it 100% of the time is the lack of PWA support, which this extension could remedy. EDIT: PWA launches only if run through CLI, but not browser UI, although I'm getting this: But I'm assuming it's not as big of a deal since it still worked? |
|
Hi all, please review this PR NixOS/nixpkgs#263404. For me it works on all my NixOS machines, so maybe we can finally close this issue. |
This prevents installing and uninstalling the runtime using commands, and also stops patching the runtime when launching web apps. The runtime can still be patched manually from the extension settings or the patch command if the user has sufficient write permissions to do so. This is meant for immutable systems like Guix or Nix where runtime might be provided by the package manager and pre-patched. See #204 for more.
|
I've added a command option I've also added a Cargo feature These features will be available in the next release. I'm not sure how far the attempts to use Also, I previously said that the runtime can only be installed in So, in case you decide to use the
Please let me know if there are any other things related to Nix (and Guix) that I could do to make packaging easier. |
|
Hi, the packaging I suggested works flawlessly (no error/warning at Firefox launch, all the libraries are found using the native NixOS wrapping tools). I even wrote a NixOS test to prove that FirefoxPWA on NixOS works. Just to understand this discussion, we are talking about a refinement to avoid downloading the Firefox client on NixOS? But we agree that FirefoxPWA on NixOS is already perfectly functional as is? However, when it is released, I can add this new feature in the NixOS packaging process, I agree that it would be even cleaner to patch Firefox once and for all in the Nix Store. Thank you @filips123 for your help! |
If it works fine without the immutable runtime (which prevents downloading normal Firefox from Mozilla), that's great! If that additional featue to use the immutable runtime is added, I think it would be good if it's optional (so, that user decides whether to use it when installing the package, if that's possible), as users might still want to download Firefox automatically or use other compatible Firefox-based browsers. |
|
Ok! I think we gare nearly ready! Thanks again for your changes. Now my web apps use the |
|
I've added some basic installation instructions for NixOS in the extension:
Also, as the nixpkgs PR has been merged, I'm closing this issue. Please let me know if you have problems with Nix packaging. |
When I tried this there was something that I failed to realize, that you need to have |
|
Thank you all for the work getting this added to I just went through the steps to install the Also, I agree with the previous comment that something should be added to docs that say Here is my configuration: If you would like me to open a new issue for this please let me know. |
|
I followed instruction and installed firefoxpwa. and now i face this error when I try to launch the webapp : @filips123 : I opened an issue here : NixOS/nixpkgs#302431 but maybe you prefer I open a new issue here. |
I've managed to package the native connector for NixOS, but the extension does not recognize it as installed. I think that it has something to do with how NixOS handles installed apps. NixOS does not place applications in /usr/bin, instead each application has it's own path in the nix store. @filips123 I'm asking for help for making the package recognizable by the extension.
The text was updated successfully, but these errors were encountered: