retroshare: 0.6.2 -> 0.6.4

[Reilithion]

Fixed build with two patches. One fixes the libupnp update. The other
adds some missing QT include lines.

Motivation for this change

retroshare package was broken, and out of date. This fixes both.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Assured whether relevant documentation is up to date
• Fits CONTRIBUTING.md.

---

[infinisil]

Are these patches self-written or do they have an original source? If the latter (which would be preferable), you should use fetchpatch to get them instead

[Reilithion]

I had to make these patches myself. At some point, I'd like to send them upstream, but I need to figure out how RetroShare handles library version stuff first. So it comes down to starting a dialogue with that community.

[ryantm]

Please add comments linking to upstream tracking of these patches, or explanations for why nix-specific patches are needed.

[aanderse]

@Reilithion are you still interested in proceeding with this PR?

[Reilithion]

There has been a commit to the RetroShare repo that may obsolete this pull request. It'd probably be a good idea to check on that. Relevant link: RetroShare/RetroShare#1426

[chkno]

So upstream is fixed, but the fixes have not yet made it into a release. Also, this PR started as a version bump to 0.6.4, but 0.6.5 was released in the mean time (before the libupnp fixes).

Options from here:

1. Leave retroshare broken until 0.6.6 is released. :(
2. Use these patches against 0.6.4 to get 0.6.4 instead of 0.6.5. :(
3. Pick a retroshare git revision between releases, like 16115aaf4ae0 (when the libupnp fixes were merged) or whatever's the tip of master today. These will have had less testing than proper released versions, which may frustrate other users on the network if the version we pick sends them malformed or unexpected data. :(
4. Rebase upstream's libupnp fix patches to 0.6.5 and duplicate them here until 0.6.6 is released.
5. Rebase upstream's libupnp fix patches to 0.6.5, ask upstream to accept them on a 0.6.5 release branch, and reference that branch here. Upstream has a bunch of other old branches, so maybe that's normal for them.

[aanderse]

ping @chkno @Reilithion - any decision?

[Reilithion]

I do not currently have a way to test whether any particular build of Retroshare actually works on NixOS. I therefore can't meaningfully contribute to any option other than 1 or 2. I agree that one of the rebasing options sounds closer to optimal, but I can't make them happen at the moment.

[chkno]

I suppose another option would be to
6. Split libupnp, leaving pkgs/development/libraries/pupnp/default.nix to march forward normally but add pkgs/development/libraries/pupnp/pupnp-1.6.nix that's locked to the 1.6.x branch so retroshare can still use it until retroshare 0.6.6 is released. It looks like the pupnp 1.6 -> 1.8 version bump was initially reverted over compatibility concerns in 0a92fb9 before later being auto-updated again in ce0f4a1.

Any thoughts from retroshare maintainer @domenkozar or pupnp compatibility champion @Mic92 ?

[Mic92]

There is 0.6.5 out now.

[chkno]

0.6.5 has the same trouble with recent libupnp.

There's an upstream issue requesting a new release.

[stale]

Hello, I'm a bot and I thank you in the name of the community for your contributions.

Nixpkgs is a busy repository, and unfortunately sometimes PRs get left behind for too long. Nevertheless, we'd like to help committers reach the PRs that are still important. This PR has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

If this is still important to you and you'd like to remove the stale label, we ask that you leave a comment. Your comment can be as simple as "still important to me". But there's a bit more you can do:

If you received an approval by an unprivileged maintainer and you are just waiting for a merge, you can @ mention someone with merge permissions and ask them to help. You might be able to find someone relevant by using Git blame on the relevant files, or via GitHub's web interface. You can see if someone's a member of the nixpkgs-committers team, by hovering with the mouse over their username on the web interface, or by searching them directly on the list.

If your PR wasn't reviewed at all, it might help to find someone who's perhaps a user of the package or module you are changing, or alternatively, ask once more for a review by the maintainer of the package/module this is about. If you don't know any, you can use Git blame on the relevant files, or GitHub's web interface to find someone who touched the relevant files in the past.

If your PR has had reviews and nevertheless got stale, make sure you've responded to all of the reviewer's requests / questions. Usually when PR authors show responsibility and dedication, reviewers (privileged or not) show dedication as well. If you've pushed a change, it's possible the reviewer wasn't notified about your push via email, so you can always officially request them for a review, or just @ mention them and say you've addressed their comments.

Lastly, you can always ask for help at our Discourse Forum, or more specifically, at this thread or at #nixos' IRC channel.

[ehmry]

0.6.6 is out.

[Stekke]

PR for 0.6.6 #124177