is the buildfhsuserenv really necessary? There's a lot of implications of using it

It's the backbone of appimageTools. I wouldn't use it directly, but I had to modify the fonts for the bugfix. Afaik there is no way to get an appimage to work outside FHS

The bit at https://github.com/hlissner/dotfiles/blob/91fdcf590845632f2846a3fd39ad497738e829a8/packages/ripcord.nix#L23, is wholly unneeded if you read the documention on gtk3 apps and wrapGAppsHook https://nixos.org/nixpkgs/manual/#sec-language-gnome.
It's needed even in an FHS environment because we isolate gsettings schemas out of their FHS directory.

I've added that, have I done it right? Not entirely sure on the implications, especially in Qt apps.

@worldofpeace can you take a quick look?

So this is the problem I see with

  fontsConf = makeFontsConf {
    fontDirectories = [
      twemoji-color-font
    ];
  };

this makes an incongruity with the emoji font configured with the system.

But I don't see a better way to fix it 😦

It's probably best to not have this package at all, if that fix isn't included, since any other emoji font will result in painful rendering (and as I mentioned before, the developer does not see reason to fix that). If you think that keeps it from merging I'm happy to close

It's probably best to not have this package at all, if that fix isn't included, since any other emoji font will result in painful rendering (and as I mentioned before, the developer does not see reason to fix that). If you think that keeps it from merging I'm happy to close

It seems that text only/black emoji was causing the issues " Text-only emoji turns the whole line blank under Arch". In NixOS we default use color emoji.

Not entirely accurate from my experience - I had the default nixos fonts and the bug manifested. I investigated a bit ant it seems having noto-fonts pulled in is what does it (arch peoples' experiences seemed to agree)

being largely ignorant of the current font/emoji situation in nixpkgs, I'm fine with a properly rendered (even if different) emoji fonts.

But I don't see a better way to fix it 😦

Unfortunately, it look likes appimages requires a buildFHSUserEnv :(

Maybe the runscript can see if $XDG_DATA_HOME/fonts exists and try to reference that instead.

I'd like to say 2 things :

• i discover nix working on appimage, so i quit appimage and now contributing nix.
• appimages doesn't require buildFHSUserEnv , see my example in ./pkgs/applications/networking/p2p/soulseekqt but please better use p7zip method in soulseekqt: fix icons, change unpack method, update homepage, more generic appimage handling #75392 , i need to work on unify this alternative later. (appimage is defected by design, all they need is learn nixpkgs).

It's increasingly more common for people to release their application as an appimage, thought it was their way of distributing the application. Thanks!

I'm working to have proper cold reading of appimage offset and type instead rely on some p7zip magic to detect sub-filesystem. Basically, the offset we need is after elf (at time i write a few lines Makefile tool that build appimage without all their ugly stuff appimagekit) , see appimage creator gist of the simple calculation https://gist.github.com/probonopd/a490ba3401b5ef7b881d5e603fa20c93

Interesting. I will have a go at this when I get a chance

I've update the method i use to unpack appimage, https://github.com/NixOS/nixpkgs/blob/de0af4a171280f085c6181b7477cefb46cc1ae83/pkgs/applications/networking/p2p/soulseekqt/default.nix#L34-L36 , this one-liner took me sometime to write, but did the right calculation imho (not rabin2 -Z for example). Would be interesting to port that later in a build-support, but i need to do same for appimagetype handling.

Wait, that is in the wrapper.

@worldofpeace my thoughts exactly. works for me...

@worldofpeace my thoughts exactly. works for me...

perhaps @bignaux is running a different version of your commits?
Anyways, the above changes will probably eliminate some issues with qt.

duplicate with #71066

Managed to patch the binary so it's using exclusively pure dependencies and no libraries are bundled. Assuming the jump from libsodium.so.18 to libsodium.so.23 doesn't break anything, this is an entirely pure version of the the derivation. If it does break things, at least libsodium will have to be bundled and I'm probably going to pop an anyeurism.

otherwise LGTM

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/111

I decline to maintain this because the state and management of pull requests for nixpkgs is going to be the death of me. Someone else can use this code if they'd like to merge this later, and I'll be using this patched into my nixpkgs, but otherwise closing.

i understand @bqv , nixpkgs suffers of being able to delegate, and @worldofpeace with their powerful RM manager when reviewing stuff, let people thinks the issue is in good hands, but in reality, they suffers of being able to merge something ... i'm sorry for yourself but this issue is a good example how nixpkgs is maintaining.

because the state and management of pull requests for nixpkgs is going to be the death of me

Which part of the process? I looks to me like there was a lot of review going on and people were happy with the final solution, so what prompted you to close this PR?

Specifically the fact that I've been posting this PR in #nixos on freenode almost every day, hoping someone would pay attention to it and maybe even merge it. I have nothing against the back and forth and PR critique, but the fact that it's so common for PRs to just be ignored for years, and the fact that this one was repeatedly ignored for days despite working on most levels at every stage is what bothers me.

Only when I threw a loud fit in #nixos did anyone pay any attention and now this package is merged, but I want nothing to do with it because the original problem remains: nixpkgs PRs are just an exercise in extremely slow torture.

unfortunately, there's just too little committers for the number of PRs. When I first started to get active with nixpkgs, there was around 1400 PRs/month (may 2019), now we are 2400+ PRs/month. And I think we've added 3 committers since then.

I only have a certain number of hours to dedicate to nixpkgs, and as many PRs as i get through, is how many I'm able to address.

nixpkgs is not able to delegate , that's just the point here. i'm sure a lot of valuable people can help but they don't stay because of that.

I'll reiterate that what I'm blaming here isn't any particular person, it's the design of this system which I find flaws with and that are the source of my massive frustration here

i'm really sorry i try the best i can to make nixpkgs change poliitics of being an insider trip but it's not that easy. you know, when people are community-based, they don't see how they are hurting the full process.

Specifically the fact that I've been posting this PR in #nixos on freenode almost every day, hoping someone would pay attention to it and maybe even merge it. I have nothing against the back and forth and PR critique, but the fact that it's so common for PRs to just be ignored for years, and the fact that this one was repeatedly ignored for days despite working on most levels at every stage is what bothers me.

@bqv @bignaux I think we all agree with the sentiment, but I also think your're being slightly unfair to the process.

You've packaged a proprietary, Qt GUI app and faced multiple bumps along the way; that makes it quite a bit harder than the average package (of which we do merge many, especially the easy ones, quite quickly).

You've fixed all the bumps and done a good job!

There are lots of people who appreciate that you've put in the time to get it done, and there will be much more in the future now that it's easily installable.

The right thing to do now is to PR yourself as co-maintainer into

This (having more maintainers) is what will solve the fundamental issue.

(Also, building more automation is on the way, and it will likely reduce load on nixpkgs PRs significantly, and thus free up more reviewer time.)