jiebi/CodeConvo huggingface dataset:
Code change:
Project description Desktop client for the LBRY protocol. A YouTube alternative that uses the blockchain. Metadata homepage URL: source URL: license: MIT platforms: Linux
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue 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. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Still not packaged.
Work has been started in .
I marked this as stale due to inactivity. &rarr;
still actual
PR
PR closed, anyone else willing, reopen under a new PR and try your luck at the merge roulette
Small update, I'm currently working on packaging LBRY from source (it actually seems possible).
Ok, while not from source (that didn't work out) LBRY has been packaged.

Related discussion:
text: githubId = 18535642; name = "Emily"; }; <ins> enderger = { email = "endergeryt@gmail.com"; github = "enderger"; githubId = 36283171; name = "Daniel"; }; </ins> endocrimes = { email = "dani@builds.terrible.systems"; github = "endocrimes";
Code change:
Project description Desktop client for the LBRY protocol. A YouTube alternative that uses the blockchain. Metadata homepage URL: source URL: license: MIT platforms: Linux
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue 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. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Still not packaged.
Work has been started in .
I marked this as stale due to inactivity. &rarr;
still actual
PR
PR closed, anyone else willing, reopen under a new PR and try your luck at the merge roulette
Small update, I'm currently working on packaging LBRY from source (it actually seems possible).
Ok, while not from source (that didn't work out) LBRY has been packaged.

Related discussion:
text: <ins> { lib, fetchurl, appimageTools}: let pname = "lbry-desktop"; version = "0.50.2"; in appimageTools.wrapAppImage rec { name = "${pname}-${version}"; # Fetch from GitHub Releases and extract src = appimageTools.extract { inherit name; src = fetchurl { url = "https://github.com/lbryio/lbry-desktop/releases/download/v${version}/LBRY_${version}.AppImage"; # Gotten from latest-linux.yml sha512 = "br6HvVRz+ybmAhmQh3vOC5wgLmOCVrGHDn59ueWk6rFoKOCbm8WdmdadOZvHeN1ld2nlvPzEy+KXMOEfF1LeQg=="; }; }; # At runtime, Lbry likes to have access to Ffmpeg extraPkgs = pkgs: with pkgs; [ ffmpeg ]; # General fixup extraInstallCommands = '' # Firstly, rename the executable to lbry for convinence mv $out/bin/${name} $out/bin/lbry # Now, install assets such as the desktop file and icons install -m 444 -D ${src}/lbry.desktop -t $out/share/applications substituteInPlace $out/share/applications/lbry.desktop  --replace 'AppRun' '$out/bin/lbry' cp -r ${src}/usr/share/icons $out/share ''; meta = with lib; { description = "A browser and wallet for LBRY, the decentralized, user-controlled content marketplace"; longDescription = '' The LBRY app is a graphical browser for the decentralized content marketplace provided by the LBRY protocol. It is essentially the lbry daemon bundled with a UI using Electron. ''; license = licenses.mit; homepage = "https://lbry.com/"; downloadPage = "https://lbry.com/get/"; changelog = "https://github.com/lbryio/lbry-desktop/blob/master/CHANGELOG.md"; maintainers = with maintainers; [ enderger ]; platforms = [ "x86_64-linux" ]; }; } </ins>
Code change:
Project description Desktop client for the LBRY protocol. A YouTube alternative that uses the blockchain. Metadata homepage URL: source URL: license: MIT platforms: Linux
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue 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. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Still not packaged.
Work has been started in .
I marked this as stale due to inactivity. &rarr;
still actual
PR
PR closed, anyone else willing, reopen under a new PR and try your luck at the merge roulette
Small update, I'm currently working on packaging LBRY from source (it actually seems possible).
Ok, while not from source (that didn't work out) LBRY has been packaged.

Related discussion:
text: lbdb = callPackage ../tools/misc/lbdb { abook = null; gnupg = null; goobook = null; khard = null; mu = null; }; <ins> lbry = callPackage ../applications/video/lbry { }; </ins> lbzip2 = callPackage ../tools/compression/lbzip2 { }; lci = callPackage ../applications/science/logic/lci {};
Code change:
Describe the bug NixOS’ Reaper package is not configured to work with Jack2 backend. To Reproduce Expected behavior Reaper should manage jack backend. See for instance . For now, Reaper only says in Reaper Preferences/Audio/Device. Additional context Everything is working fine on my system with jack2 (Ardour, Supercollider, VLC, etc.), except Reaper. Metadata

Related discussion:
text: { stdenv, fetchurl, autoPatchelfHook, makeWrapper <del> , alsaLib, xorg </del> <ins> , alsaLib, xorg, libjack2 </ins> , gtk3, pango, gdk-pixbuf, cairo, glib, freetype , libpulseaudio, xdg_utils }: stdenv.mkDerivation rec { pname = "reaper"; <del> version = "5.987"; </del> <ins> version = "6.10"; </ins> src = fetchurl { url = "https://www.reaper.fm/files/${stdenv.lib.versions.major version}.x/reaper${builtins.replaceStrings ["."] [""] version}_linux_x86_64.tar.xz"; <del> sha256 = "040k5inzj7mmi75fc6hr0ym18y5xss1675bl5rmhn4sq535m289k"; </del> <ins> sha256 = "1p54phmsa6xbqxb5cpgwnz7ny4famb8zi25y3cmxwgr4pfy94b2p"; </ins> }; nativeBuildInputs = [ autoPatchelfHook makeWrapper ];
Code change:
Describe the bug NixOS’ Reaper package is not configured to work with Jack2 backend. To Reproduce Expected behavior Reaper should manage jack backend. See for instance . For now, Reaper only says in Reaper Preferences/Audio/Device. Additional context Everything is working fine on my system with jack2 (Ardour, Supercollider, VLC, etc.), except Reaper. Metadata

Related discussion:
text: rm $out/opt/REAPER/uninstall-reaper.sh wrapProgram $out/opt/REAPER/reaper  <del> --prefix LD_LIBRARY_PATH : ${libpulseaudio}/lib </del> <ins> --prefix LD_LIBRARY_PATH : "${stdenv.lib.makeLibraryPath [ libpulseaudio libjack2 ]}" </ins> mkdir $out/bin ln -s $out/opt/REAPER/reaper $out/bin/
Code change:
Describe the bug When I launch using a keyboard shortcut, it didn't get any context, resulting in it displaying strangely: ! If I launch it using the menu it displays correctly. For other applications, depending on what they requires, they sometime just don't open. EDIT : I have the feeling that the reason that is not opening when using the keybinding is the same reason. To Reproduce Steps to reproduce the behavior: a shortcut to Konsole konsole with the shortcut Additional information While starting with the shortcut, this inputs is visible in : Expected behavior The program should behave the same way as when launched using menu. Metadata Maintainer information:
Woah, it doesn't seem to even have a PATH environment.
New way to reproduce the issue : when the feature to restore previous window after a logout/login is active, it restarts the application with the same issue.
Applying the fix from fixed this issue.
I cherry-picked and it fixed this issue for me; however my KDE windows are all still borderless.
Hmm, that sounds like kwin died.

Related discussion:
text: <ins> From 715c5f461b4992dac066601202a673bc551a5e33 Mon Sep 17 00:00:00 2001 From: Thomas Tuegel <ttuegel@mailbox.org> Date: Sun, 16 Feb 2020 14:23:31 -0600 Subject: [PATCH 1/4] kinit-libpath --- src/kdeinit/kinit.cpp | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/src/kdeinit/kinit.cpp b/src/kdeinit/kinit.cpp index 8fff17a..0801b75 100644 --- a/src/kdeinit/kinit.cpp +++ b/src/kdeinit/kinit.cpp @@ -622,19 +622,15 @@ static pid_t launch(int argc, const char *_name, const char *args, if (!libpath.isEmpty()) { if (libpath_relative) { -                // NB: Because Qt makes the actual dlopen() call, the -                //     RUNPATH of kdeinit is *not* respected - see -                //     https://sourceware.org/bugzilla/show_bug.cgi?id=13945 -                //     - so we try hacking it in ourselves -                QString install_lib_dir = QFile::decodeName( -                        CMAKE_INSTALL_PREFIX "/" LIB_INSTALL_DIR "/"); -                QString orig_libpath = libpath; -                libpath = install_lib_dir + libpath; -                l.setFileName(libpath); -                if (!l.load()) { -                    libpath = orig_libpath; -                    l.setFileName(libpath); -                    l.load(); +                // Try to load the library relative to the active profiles. +                QByteArrayList profiles = qgetenv("NIX_PROFILES").split(' '); +                // Reverse the profile list. +                std::reverse(profiles.begin(), profiles.end()); +                for (const QByteArray &profile: profiles) { +                    if (!profile.isEmpty()) { +                        l.setFileName(QFile::decodeName(profile) + QStringLiteral("/lib/") + libpath); +                        if (l.load()) break; +                    } } } else { l.load(); -- 2.23.1 </ins>
Code change:
Describe the bug When I launch using a keyboard shortcut, it didn't get any context, resulting in it displaying strangely: ! If I launch it using the menu it displays correctly. For other applications, depending on what they requires, they sometime just don't open. EDIT : I have the feeling that the reason that is not opening when using the keybinding is the same reason. To Reproduce Steps to reproduce the behavior: a shortcut to Konsole konsole with the shortcut Additional information While starting with the shortcut, this inputs is visible in : Expected behavior The program should behave the same way as when launched using menu. Metadata Maintainer information:
Woah, it doesn't seem to even have a PATH environment.
New way to reproduce the issue : when the feature to restore previous window after a logout/login is active, it restarts the application with the same issue.
Applying the fix from fixed this issue.
I cherry-picked and it fixed this issue for me; however my KDE windows are all still borderless.
Hmm, that sounds like kwin died.

Related discussion:
text: <ins> From 129cd0ae1e983adc10dbe84e87bcc6f31cb13db8 Mon Sep 17 00:00:00 2001 From: Thomas Tuegel <ttuegel@mailbox.org> Date: Sun, 16 Feb 2020 14:23:44 -0600 Subject: [PATCH 2/4] start_kdeinit-path --- src/start_kdeinit/start_kdeinit_wrapper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/start_kdeinit/start_kdeinit_wrapper.c b/src/start_kdeinit/start_kdeinit_wrapper.c index 891f50c..ef664ad 100644 --- a/src/start_kdeinit/start_kdeinit_wrapper.c +++ b/src/start_kdeinit/start_kdeinit_wrapper.c @@ -23,7 +23,7 @@ #include <string.h> #include <unistd.h> -#define EXECUTE CMAKE_INSTALL_FULL_LIBEXECDIR_KF5 "/start_kdeinit" +#define EXECUTE "/run/wrappers/bin/start_kdeinit" #if KDEINIT_OOM_PROTECT -- 2.23.1 </ins>
Code change:
Describe the bug When I launch using a keyboard shortcut, it didn't get any context, resulting in it displaying strangely: ! If I launch it using the menu it displays correctly. For other applications, depending on what they requires, they sometime just don't open. EDIT : I have the feeling that the reason that is not opening when using the keybinding is the same reason. To Reproduce Steps to reproduce the behavior: a shortcut to Konsole konsole with the shortcut Additional information While starting with the shortcut, this inputs is visible in : Expected behavior The program should behave the same way as when launched using menu. Metadata Maintainer information:
Woah, it doesn't seem to even have a PATH environment.
New way to reproduce the issue : when the feature to restore previous window after a logout/login is active, it restarts the application with the same issue.
Applying the fix from fixed this issue.
I cherry-picked and it fixed this issue for me; however my KDE windows are all still borderless.
Hmm, that sounds like kwin died.

Related discussion:
text: <ins> From 4f5d0de7e35744cdbfa9e280ee7e15a54cf21abb Mon Sep 17 00:00:00 2001 From: Thomas Tuegel <ttuegel@mailbox.org> Date: Sun, 16 Feb 2020 14:24:07 -0600 Subject: [PATCH 3/4] kdeinit-extra-libs --- src/kdeinit/kinit.cpp | 22 ++++------------------ 1 file changed, 4 insertions(+), 18 deletions(-) diff --git a/src/kdeinit/kinit.cpp b/src/kdeinit/kinit.cpp index 0801b75..622dd5f 100644 --- a/src/kdeinit/kinit.cpp +++ b/src/kdeinit/kinit.cpp @@ -96,9 +96,9 @@ static const char *extra_libs[] = { "libKF5Parts.5.dylib", "libKF5Plasma.5.dylib" #else -    "libKF5KIOCore.so.5", -    "libKF5Parts.so.5", -    "libKF5Plasma.so.5" +    NIXPKGS_KF5_KIOCORE, +    NIXPKGS_KF5_PARTS, +    NIXPKGS_KF5_PLASMA #endif }; #endif @@ -1524,20 +1524,6 @@ static int initXconnection() } #endif -#ifndef Q_OS_OSX -// Find a shared lib in the lib dir, e.g. libkio.so. -// Completely unrelated to plugins. -static QString findSharedLib(const QString &lib) -{ -    QString path = QFile::decodeName(CMAKE_INSTALL_PREFIX "/" LIB_INSTALL_DIR "/") + lib; -    if (QFile::exists(path)) { -        return path; -    } -    // We could also look in LD_LIBRARY_PATH, but really, who installs the main libs in different prefixes? -    return QString(); -} -#endif - extern "C" { static void secondary_child_handler(int) @@ -1679,7 +1665,7 @@ int main(int argc, char **argv) #if defined(Q_OS_UNIX) && !defined(Q_OS_OSX) if (!d.suicide && qEnvironmentVariableIsEmpty("KDE_IS_PRELINKED")) { for (const char *extra_lib : extra_libs) { -            const QString extra = findSharedLib(QString::fromLatin1(extra_lib)); +            const QString extra = QString::fromLatin1(extra_lib); if (!extra.isEmpty()) { QLibrary l(extra); l.setLoadHints(QLibrary::ExportExternalSymbolsHint); -- 2.23.1 </ins>
Code change:
Describe the bug When I launch using a keyboard shortcut, it didn't get any context, resulting in it displaying strangely: ! If I launch it using the menu it displays correctly. For other applications, depending on what they requires, they sometime just don't open. EDIT : I have the feeling that the reason that is not opening when using the keybinding is the same reason. To Reproduce Steps to reproduce the behavior: a shortcut to Konsole konsole with the shortcut Additional information While starting with the shortcut, this inputs is visible in : Expected behavior The program should behave the same way as when launched using menu. Metadata Maintainer information:
Woah, it doesn't seem to even have a PATH environment.
New way to reproduce the issue : when the feature to restore previous window after a logout/login is active, it restarts the application with the same issue.
Applying the fix from fixed this issue.
I cherry-picked and it fixed this issue for me; however my KDE windows are all still borderless.
Hmm, that sounds like kwin died.

Related discussion:
text: <ins> From 41e94983dcfbc1667f1b18c5b566aa5c5975edcb Mon Sep 17 00:00:00 2001 From: Thomas Tuegel <ttuegel@mailbox.org> Date: Mon, 17 Feb 2020 04:45:03 -0600 Subject: [PATCH 4/4] start_kdeinit-environ-hard-limit --- src/start_kdeinit/start_kdeinit.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/start_kdeinit/start_kdeinit.c b/src/start_kdeinit/start_kdeinit.c index f2db3e9..4ff2602 100644 --- a/src/start_kdeinit/start_kdeinit.c +++ b/src/start_kdeinit/start_kdeinit.c @@ -148,7 +148,11 @@ int main(int argc, char **argv) ++i) { unsigned len; if (read(0, &len, sizeof(unsigned)) == sizeof(unsigned) -                            && len && len < (1 << 12)) { +                            && len) { +                        if (len >= (1 << 14)) { +                            fprintf(stderr, "%s: exceeded environment length limit", argv[0]); +                            return 1; +                        } env[ i ] = malloc(len + 1); if ((unsigned) read(0, env[ i ], len) == len) { env[ i ][ len ] = '0'; -- 2.23.1 </ins>
Code change:
Describe the bug When I launch using a keyboard shortcut, it didn't get any context, resulting in it displaying strangely: ! If I launch it using the menu it displays correctly. For other applications, depending on what they requires, they sometime just don't open. EDIT : I have the feeling that the reason that is not opening when using the keybinding is the same reason. To Reproduce Steps to reproduce the behavior: a shortcut to Konsole konsole with the shortcut Additional information While starting with the shortcut, this inputs is visible in : Expected behavior The program should behave the same way as when launched using menu. Metadata Maintainer information:
Woah, it doesn't seem to even have a PATH environment.
New way to reproduce the issue : when the feature to restore previous window after a logout/login is active, it restarts the application with the same issue.
Applying the fix from fixed this issue.
I cherry-picked and it fixed this issue for me; however my KDE windows are all still borderless.
Hmm, that sounds like kwin died.

Related discussion:
text: buildInputs = [ kconfig kcrash ki18n kio kservice kwindowsystem ]; <del> patches = copyPathsToStore (lib.readPathsFromFile ./. ./series); </del> <ins> patches = [ ./0001-kinit-libpath.patch ./0002-start_kdeinit-path.patch ./0003-kdeinit-extra-libs.patch ./0004-start_kdeinit-environ-hard-limit.patch ]; </ins> CXXFLAGS = [ ''-DNIXPKGS_KF5_KIOCORE="${getLib kio}/lib/libKF5KIOCore.so.5"'' ''-DNIXPKGS_KF5_PARTS="${getLib kparts}/lib/libKF5Parts.so.5"''
Code change:
Describe the bug When I launch using a keyboard shortcut, it didn't get any context, resulting in it displaying strangely: ! If I launch it using the menu it displays correctly. For other applications, depending on what they requires, they sometime just don't open. EDIT : I have the feeling that the reason that is not opening when using the keybinding is the same reason. To Reproduce Steps to reproduce the behavior: a shortcut to Konsole konsole with the shortcut Additional information While starting with the shortcut, this inputs is visible in : Expected behavior The program should behave the same way as when launched using menu. Metadata Maintainer information:
Woah, it doesn't seem to even have a PATH environment.
New way to reproduce the issue : when the feature to restore previous window after a logout/login is active, it restarts the application with the same issue.
Applying the fix from fixed this issue.
I cherry-picked and it fixed this issue for me; however my KDE windows are all still borderless.
Hmm, that sounds like kwin died.

Related discussion:
text: <del> Index: kinit-5.32.0/src/kdeinit/kinit.cpp =================================================================== --- kinit-5.32.0.orig/src/kdeinit/kinit.cpp +++ kinit-5.32.0/src/kdeinit/kinit.cpp @@ -96,9 +96,9 @@ static const char *extra_libs[] = { "libKF5Parts.5.dylib", "libKF5Plasma.5.dylib" #else -    "libKF5KIOCore.so.5", -    "libKF5Parts.so.5", -    "libKF5Plasma.so.5" +    NIXPKGS_KF5_KIOCORE, +    NIXPKGS_KF5_PARTS, +    NIXPKGS_KF5_PLASMA #endif }; #endif @@ -1533,20 +1531,6 @@ static int initXconnection() } #endif -#ifndef Q_OS_OSX -// Find a shared lib in the lib dir, e.g. libkio.so. -// Completely unrelated to plugins. -static QString findSharedLib(const QString &lib) -{ -    QString path = QFile::decodeName(CMAKE_INSTALL_PREFIX "/" LIB_INSTALL_DIR "/") + lib; -    if (QFile::exists(path)) { -        return path; -    } -    // We could also look in LD_LIBRARY_PATH, but really, who installs the main libs in different prefixes? -    return QString(); -} -#endif - extern "C" { static void secondary_child_handler(int) @@ -1692,7 +1676,7 @@ int main(int argc, char **argv) if (!d.suicide && qEnvironmentVariableIsEmpty("KDE_IS_PRELINKED")) { for (const char *extra_lib : extra_libs) { -            const QString extra = findSharedLib(QString::fromLatin1(extra_lib)); +            const QString extra = QString::fromLatin1(extra_lib); if (!extra.isEmpty()) { QLibrary l(extra); l.setLoadHints(QLibrary::ExportExternalSymbolsHint); </del>