Question:
libwebsockets 3.2.0 changed its behaviour in a way that breaks all versions of Mosquitto that use websockets, resulting in incoming connections being intermittent and very slow. It is fixed in their repository and will be in the next release presumably, but for now 3.2.0 is no good. If Mosquitto is the only other package using libwebsockets, I would suggest downgrading to 3.1.0, which behaves fine. Mosquitto 1.6.5, which should be released today, will refuse to compile with libwebsockets 3.2.0.
cc
mosquitto 1.6.5 fixes it - just haven't packaged it yet.
Mosquitto 1.6.5 does not fix this. There is a changelog entry which was written prior to this issue that is probably why you think it does have the fix. Sorry about that, I changed the changelog on the website post but not in the repo. The only fix for this is in libwebsockets itself.
it's pretty awesome having upstream providing proactive updates like this - much appreciated!

''; buildInputs = [ <del> openssl libuuid libwebsockets c-ares libuv </del> <ins> openssl libuuid libwebsockets_3_1 c-ares libuv </ins> ] ++ lib.optional withSystemd systemd; nativeBuildInputs = [ cmake docbook_xsl libxslt ];


Question:
libwebsockets 3.2.0 changed its behaviour in a way that breaks all versions of Mosquitto that use websockets, resulting in incoming connections being intermittent and very slow. It is fixed in their repository and will be in the next release presumably, but for now 3.2.0 is no good. If Mosquitto is the only other package using libwebsockets, I would suggest downgrading to 3.1.0, which behaves fine. Mosquitto 1.6.5, which should be released today, will refuse to compile with libwebsockets 3.2.0.
cc
mosquitto 1.6.5 fixes it - just haven't packaged it yet.
Mosquitto 1.6.5 does not fix this. There is a changelog entry which was written prior to this issue that is probably why you think it does have the fix. Sorry about that, I changed the changelog on the website post but not in the repo. The only fix for this is in libwebsockets itself.
it's pretty awesome having upstream providing proactive updates like this - much appreciated!

meta = with stdenv.lib; { description = "An open source MQTT v3.1/3.1.1 broker"; <del> homepage = http://mosquitto.org/; </del> <ins> homepage = "https://mosquitto.org/"; </ins> license = licenses.epl10; maintainers = with maintainers; [ peterhoeg ]; platforms = platforms.unix;


Question:
libwebsockets 3.2.0 changed its behaviour in a way that breaks all versions of Mosquitto that use websockets, resulting in incoming connections being intermittent and very slow. It is fixed in their repository and will be in the next release presumably, but for now 3.2.0 is no good. If Mosquitto is the only other package using libwebsockets, I would suggest downgrading to 3.1.0, which behaves fine. Mosquitto 1.6.5, which should be released today, will refuse to compile with libwebsockets 3.2.0.
cc
mosquitto 1.6.5 fixes it - just haven't packaged it yet.
Mosquitto 1.6.5 does not fix this. There is a changelog entry which was written prior to this issue that is probably why you think it does have the fix. Sorry about that, I changed the changelog on the website post but not in the repo. The only fix for this is in libwebsockets itself.
it's pretty awesome having upstream providing proactive updates like this - much appreciated!

librest = callPackage ../development/libraries/librest { }; <del> libwebsockets = callPackage ../development/libraries/libwebsockets { }; </del> <ins> inherit (callPackages ../development/libraries/libwebsockets { }) libwebsockets_3_1 libwebsockets_3_2 libwebsockets; </ins> lidarr = callPackage ../servers/lidarr { };


Question:
Describe the bug On opening Anki, I get this error My guess is the fix would be similar to (add ).
Intermediate fix: I put this in my in :

, glibcLocales , nose , jsonschema <ins> , setuptools </ins> , send2trash , CoreAudio # This little flag adds a huge number of dependencies, but we assume that


Question:
Describe the bug On opening Anki, I get this error My guess is the fix would be similar to (add ).
Intermediate fix: I put this in my in :

propagatedBuildInputs = [ pyqtwebengine sqlalchemy beautifulsoup4 send2trash pyaudio requests decorator <del> markdown jsonschema </del> <ins> markdown jsonschema setuptools </ins> ] ++ lib.optional plotsSupport matplotlib ++ lib.optional stdenv.isDarwin [ CoreAudio ]


Question:
I'm trying out NixOS 19.09 and notice that Enlightenment is still being built under X. Enlightenment 23.0 have some highlight. One of them being "Massive improvements to Wayland support".
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
It would be nice to hear about the recent progress.

, xkeyboard_config , udisks2 <ins> , waylandSupport ? false, wayland-protocols, xwayland </ins> , bluetoothSupport ? true, bluez5 , pulseSupport ? !stdenv.isDarwin, libpulseaudio }:


Question:
I'm trying out NixOS 19.09 and notice that Enlightenment is still being built under X. Enlightenment 23.0 have some highlight. One of them being "Massive improvements to Wayland support".
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
It would be nice to hear about the recent progress.

] ++ lib.optional bluetoothSupport bluez5 # for bluetooth configuration and control ++ lib.optional pulseSupport libpulseaudio # for proper audio device control and redirection <ins> ++ lib.optionals waylandSupport [ wayland-protocols xwayland ] </ins> ; patches = [


Question:
I'm trying out NixOS 19.09 and notice that Enlightenment is still being built under X. Enlightenment 23.0 have some highlight. One of them being "Massive improvements to Wayland support".
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
It would be nice to hear about the recent progress.

mesonFlags = [ "-D systemdunitdir=lib/systemd/user" <del> ]; </del> <ins> ] ++ lib.optional waylandSupport "-Dwl=true"; </ins> passthru.providedSessions = [ "enlightenment" ];


Question:
I am by no means an expert on database systems, so this may be a stupid question ... but I can't help wondering why does not refer to PostgreSQL version 11 on current versions of ? Is there a reason we haven't updated yet?
Maybe or can answer this... :thinking:
Good question. In my case I'm no longer using PostgreSQL 9 by myself and switched to 10 and 11 a long time ago, but I also wasn't aware of this because I'm not using the module from NixOS in my deployments.
Made a PR for that... If you think it's too rush to include it to 19.09, then I can delay it to 20.03 As for , it really shouldn't be used. It should be split to , and , and / may be continuosly updated, but should be used only with explicit version. But this server/client split is not straightforward, so it was not yet done.

postgresql_10 postgresql_11 ; <del> postgresql = postgresql_9_6.override { this = postgresql; }; </del> <ins> postgresql = postgresql_11.override { this = postgresql; }; </ins> postgresqlPackages = recurseIntoAttrs postgresql.pkgs; <del> postgresql11Packages = recurseIntoAttrs postgresql_11.pkgs; </del> <ins> postgresql11Packages = pkgs.postgresqlPackages; </ins> postgresql_jdbc = callPackage ../development/java-modules/postgresql_jdbc { };


Question: Describe the bug to the find call. This prevents things in the that are symlinks from being wrapped. Noticed this during office-hours when wasn't wrapped anymore. We should add some code like there is in or revert the . To Reproduce Steps to reproduce the behavior: a binary into or the thing and notice the binary isn't wrapped.

do [ -d "$targetDir" ] || continue <del> find "$targetDir" -type f -executable -print0 | while IFS= read -r -d '' file </del> <ins> find "$targetDir" ! -type d -executable -print0 | while IFS= read -r -d '' file </ins> do patchelf --print-interpreter "$file" >/dev/null 2>&1 || continue


Question:
Describe the bug In , if you enable both xserver.services.desktopManager.plasma5 and , assertion fails. Failed assertions: cmt and libinput are incompatible, you cannot enable both (in services.xserver). To Reproduce Steps to reproduce the behavior: both and Expected behavior Failed assertion should happen Additional context Build with works fine. Metadata Maintainer information: kcalvinalvin a list of nixpkgs attributes affected by the problem a list of nixos modules affected by the problem
Found the culprit. Can we disable by default so that users can choose? The default generated has the option by default so I don't see the reason why it needs to also be defaulted in

assertions = [ { assertion = !config.services.xserver.libinput.enable; <del> message = "cmt and libinput are incompatible, you cannot enable both (in services.xserver)."; </del> <ins> message = '' cmt and libinput are incompatible, meaning you cannot enable them both. To use cmt you need to disable libinput with `services.xserver.libinput.enable = false` If you haven't enabled it in configuration.nix, it's enabled by default on a different xserver module. ''; </ins> } ]; };


Question:
seems to be broken in more than one way. I get (also on ) Pinging maintainer:
That is, a build against current master with succeeds for me on NixOS 18.09 Will work on fixing that, but in the meantime you have a workaround.
Not able to reproduce this one yet
Mh yeah I wrote a patch for to handle the case of not being present and after that, this error log showed up. Edit: I found my patch. Its really simple, just to fix the error. By building with that patch, I get the error log shown above.
i build scylladb under redhat7(3.10.0-693.17.1.el7.x86_64) it fail with following information: i have enough disk for it, but i don't understand why it occupy so huge size.
The final build is for me. Haven't looked into why that is, yet. Could you open a separate issue for that? Thanks!

<ins> diff --git a/configure.py b/configure.py index 25ca951ac..454140420 100755 --- a/configure.py +++ b/configure.py @@ -36,13 +36,16 @@ tempfile.tempdir = "./build/tmp" configure_args = str.join(' ', [shlex.quote(x) for x in sys.argv[1:]]) -for line in open('/etc/os-release'): -    key, _, value = line.partition('=') -    value = value.strip().strip('"') -    if key == 'ID': -        os_ids = [value] -    if key == 'ID_LIKE': -        os_ids += value.split(' ') +try: +    for line in open('/etc/os-release'): +        key, _, value = line.partition('=') +        value = value.strip().strip('"') +        if key == 'ID': +            os_ids = [value] +        if key == 'ID_LIKE': +            os_ids += value.split(' ') +except FileNotFoundError: +    os_ids = ["linux"] # distribution "internationalization", converting package names. </ins>


Question:
seems to be broken in more than one way. I get (also on ) Pinging maintainer:
That is, a build against current master with succeeds for me on NixOS 18.09 Will work on fixing that, but in the meantime you have a workaround.
Not able to reproduce this one yet
Mh yeah I wrote a patch for to handle the case of not being present and after that, this error log showed up. Edit: I found my patch. Its really simple, just to fix the error. By building with that patch, I get the error log shown above.
i build scylladb under redhat7(3.10.0-693.17.1.el7.x86_64) it fail with following information: i have enough disk for it, but i don't understand why it occupy so huge size.
The final build is for me. Haven't looked into why that is, yet. Could you open a separate issue for that? Thanks!

fetchSubmodules = true; }; <del> patches = [ ./seastar-configure-script-paths.patch ]; </del> <ins> patches = [ ./seastar-configure-script-paths.patch ./configure-etc-osrelease.patch ]; </ins> nativeBuildInputs = [ pkgconfig


Question:
seems to be broken in more than one way. I get (also on ) Pinging maintainer:
That is, a build against current master with succeeds for me on NixOS 18.09 Will work on fixing that, but in the meantime you have a workaround.
Not able to reproduce this one yet
Mh yeah I wrote a patch for to handle the case of not being present and after that, this error log showed up. Edit: I found my patch. Its really simple, just to fix the error. By building with that patch, I get the error log shown above.
i build scylladb under redhat7(3.10.0-693.17.1.el7.x86_64) it fail with following information: i have enough disk for it, but i don't understand why it occupy so huge size.
The final build is for me. Haven't looked into why that is, yet. Could you open a separate issue for that? Thanks!

postPatch = '' patchShebangs ./configure.py <ins> patchShebangs seastar/json/json2code.py </ins> ''; configurePhase = '' ./configure.py --mode=release ''; installPhase = '' mkdir $out cp -r * $out/ ''; meta = with stdenv.lib; { description = "NoSQL data store using the seastar framework, compatible with Apache Cassandra"; homepage = "https://scylladb.com";


Question:
Describe the bug is broken on Darwin. git bisect shows (part of ) as the first failing commit To Reproduce Try to build on Darwin at <details<summarynix-build -A gobject-introspection </summary</detailsExpected behavior Able to build on Darwin Additional context <!-- There is a 10 years old bug report with the same error message --Metadata Maintainer information: cc:
Looks like this upstream issue: . It's fixed on master so we should probably pick the patches.
Our jobset needs to be building on the darwin platform if we don't want things breaking like this.

, doCheck ? config.doCheckByDefault or false , coreutils, dbus, libxml2, tzdata , desktop-file-utils, shared-mime-info <del> , darwin </del> <ins> , darwin, fetchpatch </ins> }: with stdenv.lib;


Question:
Describe the bug is broken on Darwin. git bisect shows (part of ) as the first failing commit To Reproduce Try to build on Darwin at <details<summarynix-build -A gobject-introspection </summary</detailsExpected behavior Able to build on Darwin Additional context <!-- There is a 10 years old bug report with the same error message --Metadata Maintainer information: cc:
Looks like this upstream issue: . It's fixed on master so we should probably pick the patches.
Our jobset needs to be building on the darwin platform if we don't want things breaking like this.

sha256 = "046sqfmr84blxh4vkipmh8ff7wd19fxmh6lnr5ibchx3l02p49bc"; }; <del> patches = optional stdenv.isDarwin ./darwin-compilation.patch ++ optional doCheck ./skip-timer-test.patch ++ optionals stdenv.hostPlatform.isMusl [ ./quark_init_on_demand.patch ./gobject_init_on_demand.patch ] ++ [ ./schema-override-variable.patch # Require substituteInPlace in postPatch ./fix-gio-launch-desktop-path.patch # GLib contains many binaries used for different purposes; # we will install them to different outputs: # 1. Tools for desktop environment ($bin) #    * gapplication (non-darwin) #    * gdbus #    * gio #    * gio-launch-desktop (symlink to $out) #    * gsettings # 2. Development/build tools ($dev) #    * gdbus-codegen #    * gio-querymodules #    * glib-compile-resources #    * glib-compile-schemas #    * glib-genmarshal #    * glib-gettextize #    * glib-mkenums #    * gobject-query #    * gresource #    * gtester #    * gtester-report # 3. Tools for desktop environment that cannot go to $bin due to $out depending on them ($out) #    * gio-launch-desktop ./split-dev-programs.patch ]; </del> <ins> patches = optionals stdenv.isDarwin [ ./darwin-compilation.patch # fix loading dylibs on darwin # Remove on 2.62.1 (fetchpatch { url = "https://gitlab.gnome.org/GNOME/glib/commit/e2409e5e180f1fa369d0e87e38e4d646d9f68791.patch"; sha256 = "1dhjwlsqdgnn8fr8pzfrnd63m7pdgf7mizdyn8lwg17ggvq6qsqf"; }) ] ++ optionals stdenv.hostPlatform.isMusl [ ./quark_init_on_demand.patch ./gobject_init_on_demand.patch ] ++ [ ./schema-override-variable.patch # Require substituteInPlace in postPatch ./fix-gio-launch-desktop-path.patch # GLib contains many binaries used for different purposes; # we will install them to different outputs: # 1. Tools for desktop environment ($bin) #    * gapplication (non-darwin) #    * gdbus #    * gio #    * gio-launch-desktop (symlink to $out) #    * gsettings # 2. Development/build tools ($dev) #    * gdbus-codegen #    * gio-querymodules #    * glib-compile-resources #    * glib-compile-schemas #    * glib-genmarshal #    * glib-gettextize #    * glib-mkenums #    * gobject-query #    * gresource #    * gtester #    * gtester-report # 3. Tools for desktop environment that cannot go to $bin due to $out depending on them ($out) #    * gio-launch-desktop ./split-dev-programs.patch ] ++ optional doCheck ./skip-timer-test.patch; </ins> outputs = [ "bin" "out" "dev" "devdoc" ];


Question:
Describe the bug Build fails when trying to install . I get: To Reproduce Expected behavior The package should install without error. Metadata Maintainer information:
cc
Related to
Tried the following: It doesn't even bother about the C-core Version 6 that I asked: What am I doing wrong ?
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Refreshed. My PR will fix this issue. Thanks for your patience.

stdenv.mkDerivation rec { pname = "igraph"; <del> version = "0.7.1"; </del> <ins> version = "0.8.2"; </ins> src = fetchFromGitHub { owner = "igraph"; repo = pname; rev = version; <del> sha256 = "1wsy0r511gk069il6iqjs27q8cjvqz20gf0a7inybx1bw84845z8"; </del> <ins> sha256 = "015yh9s19lmxm7l1ld8adlsqh1lrmzicl801saixdwl9w05hfva4"; </ins> }; nativeBuildInputs = [ pkgconfig autoreconfHook ]; buildInputs = [ flex yacc zlib libxml2 ]; <del> # This file is normally generated by igraph's bootstrap.sh, but we can do it # ourselves. ~ C. </del> <ins> # Normally, igraph wants us to call bootstrap.sh, which will call # tools/getversion.sh. Instead, we're going to put the version directly # where igraph wants, and then let autoreconfHook do the rest of the # bootstrap. ~ C. </ins> postPatch = '' <del> echo "${version}" > VERSION </del> <ins> echo "${version}" > IGRAPH_VERSION </ins> ''; <ins> doCheck = true; </ins> meta = { description = "The network analysis package"; homepage = "https://igraph.org/"; license = lib.licenses.gpl2; <ins> # NB: Known to fail tests on aarch64. platforms = [ "x86_64-linux" ]; </ins> maintainers = [ lib.maintainers.MostAwesomeDude ]; }; }


Question:
Describe the bug Build fails when trying to install . I get: To Reproduce Expected behavior The package should install without error. Metadata Maintainer information:
cc
Related to
Tried the following: It doesn't even bother about the C-core Version 6 that I asked: What am I doing wrong ?
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Refreshed. My PR will fix this issue. Thanks for your patience.

{ buildPythonPackage, fetchPypi, lib, isPy3k <del> , pkgconfig, igraph }: </del> <ins> , pkgconfig, igraph , texttable }: </ins> buildPythonPackage rec { pname = "python-igraph";


Question:
Describe the bug Build fails when trying to install . I get: To Reproduce Expected behavior The package should install without error. Metadata Maintainer information:
cc
Related to
Tried the following: It doesn't even bother about the C-core Version 6 that I asked: What am I doing wrong ?
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Refreshed. My PR will fix this issue. Thanks for your patience.

nativeBuildInputs = [ pkgconfig ]; buildInputs = [ igraph ]; <ins> propagatedBuildInputs = [ texttable ]; </ins> src = fetchPypi { inherit pname version; sha256 = "4601638d7d22eae7608cdf793efac75e6c039770ec4bd2cecf76378c84ce7d72"; }; <ins> # NB: We want to use our igraph, not vendored igraph, but even with # pkg-config on the PATH, their custom setup.py still needs to be explicitly # told to do it. ~ C. setupPyGlobalFlags = [ "--use-pkg-config" ]; </ins> doCheck = !isPy3k; meta = {


Question:
Describe the bug Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(hyper): channels(root): nixpkgs: Maintainer information:
I've also encountered this. I bisected it to . says there's a newer version (1.) whose release notes say "Fix two test failures on newer versions of gtk+/gnome-shell/mutter". However, updating to it does not fix this test failure. :( With 1., the exact failure I'm getting is:
When updating to GNOME 3.34 I did indeed notice this and tried the exact things did. We probably need to report it so it can be fixed, I just didn't have the time to do this. Guess the testsuite could be disabled.
Disabling tests got it to build for me. I'll try to find some time to open a PR for that, and to report it upstream.
Reported upstream:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .

sha256 = "1044rj3wbfmgaif2jb0k28m2aczli6ai2n5yvn6pr7zjyw16kvd2"; }; buildInputs = [ pkgs.gtk2 Cairo ExtUtilsDepends ExtUtilsPkgConfig Glib Pango ]; <del> doCheck = !stdenv.isDarwin; </del> <ins> # https://rt.cpan.org/Public/Bug/Display.html?id=130742 # doCheck = !stdenv.isDarwin; doCheck = false; </ins> meta = { homepage = http://gtk2-perl.sourceforge.net/; description = "Perl interface to the 2.x series of the Gimp Toolkit library";


Question:
Describe the bug sane-backends provides a configuration file, which is also produced by To Reproduce Steps to reproduce the behavior: Expected behavior No file conflict Additional context Add any other context about the problem here. Metadata Maintainer information:
Something isn't right there. I have in my , but I have no whatsoever:
The sane config is not written to /etc but only pointed at by the environment variable.
This is really just us being noisy about collisions, this one is harmless.
Even if it's harmless, what would be the preferred way of getting rid of this warning?
It doesn't really serve any purpose for nixos users, so it was fine to remove.

substituteInPlace $out/lib/libsane.la  --replace "-ljpeg" "-L${libjpeg.out}/lib -ljpeg" <ins> # net.conf conflicts with the file generated by the nixos module rm -f $out/etc/sane.d/net.conf </ins> '' + stdenv.lib.concatStrings (builtins.map installFirmware compatFirmware); meta = with stdenv.lib; {


Question:
Describe the bug To Reproduce Metadata
In darwin building graalvm results in:
Which version of Nixpkgs is this? Please use the template...
sorry I overlooked the metadata; updated it now;

# gfortran readline bzip2 lzma pcre.dev curl ed ## WIP: fastr dependencies ]; postUnpack = '' <del> cp ${stdenv.cc.cc}/include/c++/${stdenv.cc.cc.version}/stdlib.h  </del> <ins> cp ${stdenv.cc.cc}/include/c++/${lib.getVersion stdenv.cc.cc}/stdlib.h  </ins> $sourceRoot/sulong/projects/com.oracle.truffle.llvm.libraries.bitcode/include cp ${truffleMake} $TMP && mv *truffle.make truffle.make rm $sourceRoot/truffle/src/libffi/patches/others/0001-Add-mx-bootstrap-Makefile.patch


Question:
Describe the bug To Reproduce Metadata
In darwin building graalvm results in:
Which version of Nixpkgs is this? Please use the template...
sorry I overlooked the metadata; updated it now;

--replace 'protected String compilerCommand = "cc";' 'protected String compilerCommand = "${stdenv.cc}/bin/cc";' # prevent cyclical imports caused by identical <include> names substituteInPlace sulong/projects/com.oracle.truffle.llvm.libraries.bitcode/include/stdlib.h  <del> --replace '# include <cstdlib>' '# include "${stdenv.cc.cc}/include/c++/${stdenv.cc.cc.version}/cstdlib"' </del> <ins> --replace '# include <cstdlib>' '# include "${stdenv.cc.cc}/include/c++/${lib.getVersion stdenv.cc.cc}/cstdlib"' </ins> # dragonegg can't seem to compile on nix, so let's not require it substituteInPlace sulong/mx.sulong/suite.py  --replace '"requireDragonegg" : True,' '"requireDragonegg" : False,'


Question:
Running reports: To Reproduce on NixOS 19.09. . Metadata I ran but got .
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 .
I had this same problem today.
I marked this as stale due to inactivity. →
Not stale; this is still a problem on a flakes based NixOS system using

<del> { lib, stdenv, pixie, fetchFromGitHub }: </del> <ins> { lib, stdenv, fetchFromGitHub , pixie, rlwrap }: </ins> stdenv.mkDerivation rec { pname = "dust";


Question:
Running reports: To Reproduce on NixOS 19.09. . Metadata I ran but got .
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 .
I had this same problem today.
I marked this as stale due to inactivity. →
Not stale; this is still a problem on a flakes based NixOS system using

patches = [ ./make-paths-configurable.patch ]; configurePhase = '' <del> pixiePath="${pixie}/bin/pixie-vm"  </del> <ins> pixiePath="${pixie}/bin/pixie"  </ins> basePath="$out/share/dust"  <ins> rlwrapPath="${rlwrap}/bin/rlwrap"  </ins> substituteAll dust.in dust chmod +x dust '';


Question:
Running reports: To Reproduce on NixOS 19.09. . Metadata I ran but got .
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 .
I had this same problem today.
I marked this as stale due to inactivity. →
Not stale; this is still a problem on a flakes based NixOS system using

index 0000000..44a7fbd --- /dev/null +++ b/dust.in <del> @@ -0,0 +1,43 @@ </del> <ins> @@ -0,0 +1,40 @@ </ins> +#!/usr/bin/env bash + +base_path=@basePath@ +pixie_path=@pixiePath@ <ins> +rlwrap_cmd=@rlwrapPath@ </ins> + +function set_load_path() { +    load_path=""


Question:
Running reports: To Reproduce on NixOS 19.09. . Metadata I ran but got .
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 .
I had this same problem today.
I marked this as stale due to inactivity. →
Not stale; this is still a problem on a flakes based NixOS system using

+ +case $1 in +    ""|"repl") <del> +        rlwrap_cmd="" +        if [ -n "`which rlwrap`" ]; then +            rlwrap_cmd="rlwrap -aignored -n" +        fi +        $rlwrap_cmd $pixie_path $load_path </del> <ins> +        $rlwrap_cmd -aignored -n $pixie_path $load_path </ins> +        ;; +    "run") +        shift


Question:
Describe the bug As of 19.09, dolphin can't connect to smb network drives becasue kpasswdserver is unable to start up but chrashes kiod5. To Reproduce Steps to reproduce the behavior: dolphin in the address bar, or any other smb share in your network displays a timeout or access denied, check for the actual error Expected behavior Dolphin shows the smb share's content, using stored passwords if available. Screenshots : Additional context I guess this is caused by but I don't know enough about where kpasswdserver actually lives and comes from to fix this myself. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information: cc
This does not only happen when trying to connect to samba shares, in my case this issue is triggered by the baloofileextractor indexer running in background, frequently causing kiod5 to dump core.
This is the backtrace of in my case:
We need to wrap in .
What exactly needs to be wrapped there?

kbookmarks kcompletion kconfig kcoreaddons kitemviews kjobwidgets kservice kxmlgui qtbase qttools solid ]; <ins> outputs = [ "out" "dev" ]; </ins> patches = (copyPathsToStore (lib.readPathsFromFile ./. ./series)); }


Question:
I've tried the following: which should assign an alias ( happily accepts the colon syntax in NixOS). Instead it tells me: "invalid character ‘:’ in name ‘unit-network-addresses-lo:metadata.service'" I also tried: which doesn't throw an error but also doesn't get me an alias. Is it not currently possible to alias the loopback interface via NixOS configuration, or am I missing something?
(triage) any leads?
More than question I think it's a bug that it doesn't work. any thoughts?
Resolved in
Sorry, is this actually resolved? I try this in my config: And I get this: If I run the setup script by hand, it works fine. is this working for you now?
use instead: we cannot support arbitrary device names here due limitation of the script generator. Should be fine with though.
I finally had a chance to follow up on this. Using the config that suggested above, I still get these errors: does actually get the address. However, boot-up and NixOps takes a lot longer, presumably because of the timeouts. So something is still not quite right here.
That device dependency should be not according to this source code: Are you running the latest NixOS 17.09?
Ahh, no, I’m running but from a few weeks ago. I’ll try again once I’ve updated.
I still recommend to people to switch to since the scripted module is just a hack... well.
So with a recent , assigning an IP address to still causes timeouts. However, the IP address does successfully get assigned.
if the service file assign ip addresses contains a dependency, something went wrong.
I see the same:
The bug appears to be here: compared to this:
Testing this patch:

}; } // (listToAttrs (flip map interfaces (i: let <del> deviceDependency = if config.boot.isContainer </del> <ins> deviceDependency = if (config.boot.isContainer || i.name == "lo") </ins> then [] else [ (subsystemDevice i.name) ]; in


Question:
Describe the bug Packages with potentially newer versions available inside Emacs will be overriden by ELPA packages. I am running an overlay with Emacs (27) built from master. On Emacs (27) master the package has the built-in version . The package provided by ELPA is . This is currently not an issue since Emacs has not been upgraded to 27. But when it does, this is going to cause a nasty "issue": To Reproduce Steps to reproduce the behavior: the load-path and notice that it includes the seq-2.20 elpa package. Expected behavior Perhaps not not included in the load-path... This is kind of the expected behavior, but I am raising this issue as from next version if not a new seq package is released to ELPA, people will end up in an infinite loop. Additional context Add any other context about the problem here. Metadata system: host os: multi-user?: sandbox: version: nixpkgs:
Any ideas what to do about this case, is there any other packages where there potentially is a later version contained within Emacs and an older one available in ELPA?
already contains a few things mapping builtins that used to be separate packages to . This ensures that anything depending on will get the correct dependency graph while actually using the emacs builtins. The correct fix here is to map to , maybe with a conditional checking the emacs version.
I've been using a locally patched nixpkgs to remove those seq dependencies, but the solution suggested here by is so much better that I went ahead and implemented it. Please can you also take a look at the PR to see if it resolves things for you? For me the breakage was pretty severe, so easy to notice (the package did not work; so I saw the problem at startup).
Thank you, I can verify that this is working for me as well. I am sorry to let more people experience this and not patching it earlier. I already spent some initial time finding the issue and then I made a patch within my own overlay like you. Glad to see it fixed, thanks :+1:
I just discovered we have the same case for . Should that perhaps also be under a conditional? I guess if you are on an older version of Emacs you want to use the ELPA version, but if you are on the latest version you want the one bundled with Emacs as the version is more recent.
Could you make a PR to nixpkgs?

cl-lib = null; # builtin tle = null; # builtin advice = null; # builtin <ins> seq = if lib.versionAtLeast self.emacs.version "27" then null else super.seq; </ins> }; elpaPackages = super // overrides;


Question:
Describe the bug Neovim crashes when resizing windows under some circumstances. To Reproduce There are many different ways to repro, these are some reliable steps to reproduce the behavior: to create a split to open a terminal to go to other window to maximize window Expected behavior Windows should resize and there should be no crash. Additional context Originally filed at but it seems to only be affecting NixOS. The crashes only started since I upgraded from NixOS 19.03 to 19.09. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information: cc
If you have a known-good nixos revision and a known-bad nixos revision you could try the issue.
The earliest local generation on which this happens is from . The latest known-good generation is from . I'm not sure these are accurate though, I'd have expected this to have happened later.
narrowed it down to which was part of
That looks helpful. Maybe you can report upstream that the libvterm update is responsible, and ask if someone on non-nixos can reproduce it with that version of libvterm (or report which version they use).
Thanks for guiding me in the right path I opened a PR with a fix. :point_up:
Thanks for fixing this :)

stdenv.mkDerivation { pname = "libvterm-neovim"; <del> version = "2019-08-28"; </del> <ins> version = "2019-10-08"; </ins> src = fetchFromGitHub { owner = "neovim"; repo = "libvterm"; <del> rev = "1aa95e24d8f07a396aa80b7cd52f93e2b5bcca79"; sha256 = "0vjd397lqrfv4kc79i5izva4bynbymx3gllkg281fnk0b15vxfif"; </del> <ins> rev = "7c72294d84ce20da4c27362dbd7fa4b08cfc91da"; sha256 = "111qyxq33x74dwdnqcnzlv9j0n8hxyribd6ppwcsxmyrniyw9qrk"; </ins> }; buildInputs = [ perl ];


Question:
Project description A cross-platform SSH client with cloud data sync and more. Metadata homepage URL: source URL: license: unfree platforms: linux
It would be really cool, I need it too!

<ins> { atomEnv , autoPatchelfHook , dpkg , fetchurl , makeDesktopItem , makeWrapper , stdenv , udev , wrapGAppsHook }: stdenv.mkDerivation rec { pname = "termius"; version = "5.10.1"; src = fetchurl { url = "https://deb.termius.com/pool/main/t/termius-app/termius-app_${version}_amd64.deb"; sha256 = "04zh0zzyp906lf6mz3xzxybn2a55rv3vvrj0m12gnrb8kjb3pk5s"; }; desktopItem = makeDesktopItem { categories = "Network;"; comment = "The SSH client that works on Desktop and Mobile"; desktopName = "Termius"; exec = "termius-app"; genericName = "Cross-platform SSH client"; icon = "termius-app"; name = "termius-app"; }; dontBuild = true; dontConfigure = true; dontPatchELF = true; dontWrapGApps = true; nativeBuildInputs = [ autoPatchelfHook dpkg makeWrapper wrapGAppsHook ]; buildInputs = atomEnv.packages; unpackPhase = "dpkg-deb -x $src ."; installPhase = '' mkdir -p "$out/bin" cp -R "opt" "$out" cp -R "usr/share" "$out/share" chmod -R g-w "$out" # Desktop file mkdir -p "$out/share/applications" cp "${desktopItem}/share/applications/"* "$out/share/applications" ''; runtimeDependencies = [ udev.lib ]; postFixup = '' makeWrapper $out/opt/Termius/termius-app $out/bin/termius-app  "''${gappsWrapperArgs[@]}" ''; meta = with stdenv.lib; { description = "A cross-platform SSH client with cloud data sync and more"; homepage = "https://termius.com/"; downloadPage = "https://termius.com/linux/"; license = licenses.unfree; maintainers = with maintainers; [ filalex77 ]; platforms = [ "x86_64-linux" ]; }; } </ins>


Question:
Project description A cross-platform SSH client with cloud data sync and more. Metadata homepage URL: source URL: license: unfree platforms: linux
It would be really cool, I need it too!

pythonPackages = python3Packages; }; <ins> termius = callPackage ../applications/networking/termius { }; </ins> termplay = callPackage ../tools/misc/termplay { }; tewisay = callPackage ../tools/misc/tewisay { };


Question:
I was getting errors with the version of dvisvgm bundled with texlive 2019 so I created a separate, texlive-independent version which works well. (If you're curious about the issue I was seeing it was related to compatibility between ghostscript and dvisvgm. I can be more specific if anyone wants, but reporting that issue is not the main purpose of this). Here's the build expression I'm using ( is ): How would people feel about a PR with a dvisvgm package uncoupled from the texlive version in addition to the one currently there? I could name it or or something like that. Note that I'm currently using this as a separate build expression but for a PR I'd put it in the texlive bin nix file. Note also that this package can be used identically to any other texlive package. The only difference to the end user is to get an option of a newer version.
What is the issue, though?
it's been reported . The issue is apparently fixed in dvisvgm 2.7.2 (ours is 2.6.3). Here's an additional MWE to test. The same example with v2.8.1 (in the build expression above) works fine.
So what you say, is that our dvisvgm is broken because of the incompatible ghostscript version. Then, I think, we should be fixing dvisvgm for all of our users, not just those who opt into using the separate package you propose. I would prefer to just patch the version from texlive, but, unfortunately, doesn't apply cleanly, so we would have to craft our own patch or pin to 2.8.1 (in this case, need to leave a TODO comment to remind to unpin for texlive 2020).
To clarify, the idea is to generate a patch from a newer texlive version of dvisvgm and apply that to the existing derivation (along with the code comment about this being a temporary fix until 2020)?
Does fix the issue for you?

inherit (common) src; <ins> patches = [ # Fix for ghostscript>=9.27 # Backport of # https://github.com/mgieseki/dvisvgm/commit/bc51951bc90b700c28ea018993bdb058e5271e9b ./dvisvgm-fix.patch # Needed for ghostscript>=9.50 (fetchpatch { url = "https://github.com/mgieseki/dvisvgm/commit/7b93a9197b69305429183affd24fa40ee04a663a.patch"; sha256 = "1gmj76ja9xng39wxckhs9q140abixgb8rkrcfv2cdgq786wm3vag"; stripLen = 1; extraPrefix = "texk/dvisvgm/dvisvgm-src/"; }) ]; </ins> nativeBuildInputs = [ pkgconfig ]; # TODO: dvisvgm still uses vendored dependencies <del> buildInputs = [ core/*kpathsea*/ ghostscript zlib freetype potrace xxHash ]; </del> <ins> buildInputs = [ core/*kpathsea*/ ghostscript zlib freetype /*potrace xxHash*/ ]; </ins> preConfigure = "cd texk/dvisvgm";


Question:
I was getting errors with the version of dvisvgm bundled with texlive 2019 so I created a separate, texlive-independent version which works well. (If you're curious about the issue I was seeing it was related to compatibility between ghostscript and dvisvgm. I can be more specific if anyone wants, but reporting that issue is not the main purpose of this). Here's the build expression I'm using ( is ): How would people feel about a PR with a dvisvgm package uncoupled from the texlive version in addition to the one currently there? I could name it or or something like that. Note that I'm currently using this as a separate build expression but for a PR I'd put it in the texlive bin nix file. Note also that this package can be used identically to any other texlive package. The only difference to the end user is to get an option of a newer version.
What is the issue, though?
it's been reported . The issue is apparently fixed in dvisvgm 2.7.2 (ours is 2.6.3). Here's an additional MWE to test. The same example with v2.8.1 (in the build expression above) works fine.
So what you say, is that our dvisvgm is broken because of the incompatible ghostscript version. Then, I think, we should be fixing dvisvgm for all of our users, not just those who opt into using the separate package you propose. I would prefer to just patch the version from texlive, but, unfortunately, doesn't apply cleanly, so we would have to craft our own patch or pin to 2.8.1 (in this case, need to leave a TODO comment to remind to unpin for texlive 2020).
To clarify, the idea is to generate a patch from a newer texlive version of dvisvgm and apply that to the existing derivation (along with the code comment about this being a temporary fix until 2020)?
Does fix the issue for you?

<ins> diff a/texk/dvisvgm/dvisvgm-src/src/psdefs.cpp b/texk/dvisvgm/dvisvgm-src/src/psdefs.cpp --- a/texk/dvisvgm/dvisvgm-src/src/psdefs.cpp +++ b/texk/dvisvgm/dvisvgm-src/src/psdefs.cpp @@ -107,8 +107,7 @@ const char *PSInterpreter::PSDEFS = "dmode sysexec<</Normal 0/Compatible 0/Multiply 1/Screen 2/Overlay 3/SoftLight " "4/HardLight 5/ColorDodge 6/ColorBurn 7/Darken 8/Lighten 9/Difference 10/Exclus" "ion 11/Hue 12/Saturation 13/Color 14/Luminosity 15/CompatibleOverprint 16>>exc" -"h get 1(setblendmode)prcmd}def/@pdfpagecount{GS_PDF_ProcSet begin pdfdict begi" -"n(r)file pdfopen begin pdfpagecount currentdict pdfclose end end end}def/@pdfp" -"agebox{GS_PDF_ProcSet begin pdfdict begin(r)file pdfopen begin dup dup 1 lt ex" -"ch pdfpagecount gt or{pop}{pdfgetpage/MediaBox pget pop aload pop}ifelse curre" -"ntdict pdfclose end end end}def DELAYBIND{.bindnow}if "; +"h get 1(setblendmode)prcmd}def/@pdfpagecount{(r)file runpdfbegin pdfpagecount " +"runpdfend}def/@pdfpagebox{(r)file runpdfbegin dup dup 1 lt exch pdfpagecount g" +"t or{pop}{pdfgetpage/MediaBox pget pop aload pop}ifelse runpdfend}def DELAYBIN" +"D{.bindnow}if "; </ins>


Question:
, CVSSv3=9.8 (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
Unstable/master: PR ; 19.09: (staging ATM, but should get into channel within days).

# Media support MEDIA_CAMERA_SUPPORT? y MEDIA_RC_SUPPORT? y <ins> MEDIA_USB_SUPPORT y </ins> ${if kernelPlatform ? kernelExtraConfig then kernelPlatform.kernelExtraConfig else ""} ${extraConfig}


Question:
Describe the bug Fails to build with some not-supported instructions: <details</detailsTo Reproduce Steps to reproduce the behavior: (on an aarch64 machine) Expected behavior Kernel builds Maintainer information: May be caused by
Fixed already by bumping to 5.4.x, 19.09 channel just hasn't caught up yet.
Never mind, I'm not very good at interpreting bisects.
I had the same issue (I think?) when trying to install NixOS 19.09 on Raspberry Pi 3B+
Fixed in .


Question:
Describe the bug NixOS manual combined fails to build since commit . This was introduced by the changes to the package awstats. This is the output: To Reproduce Steps to reproduce the behavior: Expected behavior It should be possible to build the nixos-manual-combined without errors. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(terje): nixpkgs:
this issue was resolved in there is one more issue with docs - a warning What should it be? You can test manual builds with
this was my mistake :disappointed: I had the entry to the manual. Unfortunately I confused myself by checking the manual on another PR, and then thinking I had checked the manual for the PR. The issue was compounded by me being rather occupied on Christmas day (mostly with only cell phone but no computer), which I supposed in hindsight was a reason I shouldn't have merged the change on Christmas eve after the kids were in bed. I apologize for all the hassle. It looks like the option lost its during this PR... another thing I would have noticed if I had checked the manual... When is back they can create a PR to add a description along the lines of , unless this pressing enough you want me to file a PR today. Thanks again to all who helped out on this!
no pressure!
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

"ValidHTTPCodes" = "404"; } ''; <ins> description = "Extra configuration to be appendend to awstats.${name}.conf."; </ins> }; webService = {


Question: Project description A tiny IRC client Metadata homepage URL: source URL: license: mit platforms: linux

<ins> { stdenv , lib , rustPlatform , fetchpatch , fetchFromGitHub , pkg-config , dbus , openssl }: rustPlatform.buildRustPackage rec { pname = "tiny"; version = "0.5.1"; src = fetchFromGitHub { owner = "osa1"; repo = pname; rev = "v${version}"; sha256 = "1m57xsrc7lzkrm8k1wh3yx3in5bhd0qjzygxdwr8lvigpsiy5caa"; }; cargoSha256 = "1vj6whnx8gd5r66zric9163ddlqc4al4azj0dvhv5sq0r33871kv"; RUSTC_BOOTSTRAP = 1; nativeBuildInputs = lib.optional stdenv.isLinux pkg-config; buildInputs = lib.optionals stdenv.isLinux [ dbus openssl ]; meta = with lib; { description = "A console IRC client"; homepage = "https://github.com/osa1/tiny"; license = licenses.mit; maintainers = with maintainers; [ filalex77 ]; }; } </ins>


Question: Project description A tiny IRC client Metadata homepage URL: source URL: license: mit platforms: linux

tint2 = callPackage ../applications/misc/tint2 { }; <ins> tiny = callPackage ../applications/networking/irc/tiny { }; </ins> tixati = callPackage ../applications/networking/p2p/tixati { }; tkcvs = callPackage ../applications/version-management/tkcvs { };


Question:
Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:

, lib , buildGoPackage , fetchFromGitHub <del> , openssl_1_0_2 </del> <ins> , openssl </ins> , pkgconfig , libpcap }:


Question:
Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:

}; nativeBuildInputs = [ pkgconfig ]; <del> buildInputs = [ openssl_1_0_2 libpcap ]; </del> <ins> buildInputs = [ openssl libpcap ]; </ins> # Mongodb incorrectly names all of their binaries main # Let's work around this with our own installer


Question:
Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:

<del> { stdenv, fetchFromGitHub, cmake, boost, openssl, asio }: </del> <ins> { stdenv, fetchFromGitHub, cmake, boost, openssl }: </ins> stdenv.mkDerivation rec { pname = "cpp-netlib";


Question:
Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:

buildInputs = [ cmake boost openssl ]; <del> # This can be removed when updating to 0.13, see https://github.com/cpp-netlib/cpp-netlib/issues/629 propagatedBuildInputs = [ asio ]; </del> cmakeFlags = [ "-DCPP-NETLIB_BUILD_SHARED_LIBS=ON" ]; enableParallelBuilding = true; <ins> # The test driver binary lacks an RPath to the library's libs preCheck = '' export LD_LIBRARY_PATH=$PWD/libs/network/src ''; # Most tests make network GET requests to various websites doCheck = false; </ins> meta = with stdenv.lib; { <del> description = "Collection of open-source libraries for high level network programming"; </del> <ins> description = "Collection of open-source libraries for high level network programming"; </ins> homepage    = https://cpp-netlib.org; license     = licenses.boost; platforms   = platforms.all;


Question:
Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:

cpp-ipfs-api = callPackage ../development/libraries/cpp-ipfs-api { }; <del> cpp-netlib = callPackage ../development/libraries/cpp-netlib { openssl = openssl_1_0_2; }; </del> <ins> cpp-netlib = callPackage ../development/libraries/cpp-netlib {}; </ins> uri = callPackage ../development/libraries/uri { }; cppcms = callPackage ../development/libraries/cppcms { };


Question:
Describe the bug Not able to install pycuda. Error To Reproduce Install pycuda Expected behavior install pycuda with dependencies Metadata Please run and paste the result.
Is nobody having this issue it seems is not solved :(
I'm having this issue, incoming PR. Likely half of the problem is that the cudatoolkit is pinned to 7.5 and cuda root is not passed during the build process, which is not compatible with newer cards. The other half of the problem is that python3 boost isn't being linked. I see boost is mentioned as not being necessary for pycuda in the docs, so I'm wondering if we can just remove it.
try and let me know if it works for you

, python , mkDerivation , stdenv <del> , isPy3k </del> }: let compyte = import ./compyte.nix {


Question:
Describe the bug Not able to install pycuda. Error To Reproduce Install pycuda Expected behavior install pycuda with dependencies Metadata Please run and paste the result.
Is nobody having this issue it seems is not solved :(
I'm having this issue, incoming PR. Likely half of the problem is that the cudatoolkit is pinned to 7.5 and cuda root is not passed during the build process, which is not compatible with newer cards. The other half of the problem is that python3 boost isn't being linked. I see boost is mentioned as not being necessary for pycuda in the docs, so I'm wondering if we can just remove it.
try and let me know if it works for you

sha256 = "ada56ce98a41f9f95fe18809f38afbae473a5c62d346cfa126a2d5477f24cc8a"; }; <del> preConfigure = '' </del> <ins> preConfigure = with stdenv.lib.versions; '' </ins> ${python.interpreter} configure.py --boost-inc-dir=${boost.dev}/include  --boost-lib-dir=${boost}/lib  --no-use-shipped-boost  <del> --boost-python-libname=boost_python${stdenv.lib.optionalString isPy3k "3"} </del> <ins> --boost-python-libname=boost_python${major python.version}${minor python.version}  --cuda-root=${cudatoolkit} </ins> ''; postInstall = ''


Question:
Describe the bug Not able to install pycuda. Error To Reproduce Install pycuda Expected behavior install pycuda with dependencies Metadata Please run and paste the result.
Is nobody having this issue it seems is not solved :(
I'm having this issue, incoming PR. Likely half of the problem is that the cudatoolkit is pinned to 7.5 and cuda root is not passed during the build process, which is not compatible with newer cards. The other half of the problem is that python3 boost isn't being linked. I see boost is mentioned as not being necessary for pycuda in the docs, so I'm wondering if we can just remove it.
try and let me know if it works for you

pycares = callPackage ../development/python-modules/pycares { }; pycuda = callPackage ../development/python-modules/pycuda { <del> cudatoolkit = pkgs.cudatoolkit_7_5; </del> <ins> cudatoolkit = pkgs.cudatoolkit; </ins> inherit (pkgs.stdenv) mkDerivation; };


Question:
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. →
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.

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";


Question:
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. →
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.

<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>


Question:
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. →
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.

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 {};


Question: 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

{ 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 ];


Question: 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

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/


Question:
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.

<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>


Question:
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.

<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>


Question:
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.

<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>


Question:
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.

<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>


Question:
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.

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"''


Question:
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.

<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>


Question:
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.

<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 @@ -623,19 +623,15 @@ static pid_t launch(int argc, const char 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(); </del>


Question:
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.

<del> Index: kinit-5.24.0/src/start_kdeinit/start_kdeinit_wrapper.c =================================================================== --- kinit-5.24.0.orig/src/start_kdeinit/start_kdeinit_wrapper.c +++ kinit-5.24.0/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 </del>


Question:
Describe the bug bazel broken on darwin in nixpkgs HEAD () To Reproduce Steps to reproduce the behavior: to build bazel on darwin Expected behavior Able to build bazel on darwin Additional context might be related to Metadata Please run and paste the result. Maintainer information: cc:
The bazel build is passing LDFLAGS flags to the compiler instead of the linker. Those should be prefixed with or moved somewhere else.
Clang used as a frontend should accept linker flags.
Flags were in .

postPatch = let darwinPatches = '' <ins> bazelLinkFlags () { eval set -- "$NIX_LDFLAGS" local flag for flag in "$@"; do printf ' -Wl,%s' "$flag" done } </ins> # Disable Bazel's Xcode toolchain detection which would configure compilers # and linkers from Xcode instead of from PATH export BAZEL_USE_CPP_ONLY_TOOLCHAIN=1


Question:
Describe the bug bazel broken on darwin in nixpkgs HEAD () To Reproduce Steps to reproduce the behavior: to build bazel on darwin Expected behavior Able to build bazel on darwin Additional context might be related to Metadata Please run and paste the result. Maintainer information: cc:
The bazel build is passing LDFLAGS flags to the compiler instead of the linker. Those should be prefixed with or moved somewhere else.
Clang used as a frontend should accept linker flags.
Flags were in .

# Framework search paths aren't added by bintools hook # https://github.com/NixOS/nixpkgs/pull/41914 <del> export NIX_LDFLAGS="$NIX_LDFLAGS -F${CoreFoundation}/Library/Frameworks -F${CoreServices}/Library/Frameworks -F${Foundation}/Library/Frameworks" </del> <ins> export NIX_LDFLAGS+=" -F${CoreFoundation}/Library/Frameworks -F${CoreServices}/Library/Frameworks -F${Foundation}/Library/Frameworks" </ins> # libcxx includes aren't added by libcxx hook # https://github.com/NixOS/nixpkgs/pull/41589 export NIX_CFLAGS_COMPILE="$NIX_CFLAGS_COMPILE -isystem ${libcxx}/include/c++/v1" # don't use system installed Xcode to run clang, use Nix clang instead <del> sed -i -E "s;/usr/bin/xcrun (--sdk macosx )?clang;${stdenv.cc}/bin/clang $NIX_CFLAGS_COMPILE $NIX_LDFLAGS -framework CoreFoundation;g"  </del> <ins> sed -i -E "s;/usr/bin/xcrun (--sdk macosx )?clang;${stdenv.cc}/bin/clang $NIX_CFLAGS_COMPILE $(bazelLinkFlags) -framework CoreFoundation;g"  </ins> scripts/bootstrap/compile.sh  src/tools/xcode/realpath/BUILD  src/tools/xcode/stdredirect/BUILD


Question:
Describe the bug Installing nomachine-client fails To Reproduce Steps to reproduce the behavior: to environment.systemPackages Expected behavior It should build the derivation Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
I tried overriding the hash (any tip on how to more properly do this would be appreciated), but still got build errors in my under environment.systemPackages result:
There's a PR to upgrade : I this to my and it seems to be working for me:
Yep, this is because NoMachine removes each old release as soon as they make a new one. To combat this, I'll add to the sources list when the update is done.
I was finding at the time that even overriding with the latest URL and hash from the nomachine website, that it was failing to download the whole blob. I could do it from my browser, but it seemed to abort/not download the full size via nixos
Oh, that's strange.. Thankfully, it seems to work just fine now :)

{ stdenv, file, fetchurl, makeWrapper, autoPatchelfHook, jsoncpp, libpulseaudio }: let <del> versionMajor = "6.9"; versionMinor = "2"; </del> <ins> versionMajor = "6.10"; versionMinor = "12"; </ins> versionBuild_x86_64 = "1"; versionBuild_i686 = "1"; in stdenv.mkDerivation rec { pname = "nomachine-client"; version = "${versionMajor}.${versionMinor}"; src = if stdenv.hostPlatform.system == "x86_64-linux" then fetchurl { url = "https://download.nomachine.com/download/${versionMajor}/Linux/nomachine_${version}_${versionBuild_x86_64}_x86_64.tar.gz"; <del> sha256 = "1z2pcfkzicjma4lxrj4qx43xyml993v7qyjd7k8xy8hw85fwnzii"; </del> <ins> sha256 = "17yb377ry7i7cmkb72xmhyqkfggv1ygqlz55ymvmrs7psbh7ql01"; </ins> } else if stdenv.hostPlatform.system == "i686-linux" then fetchurl { url = "https://download.nomachine.com/download/${versionMajor}/Linux/nomachine_${version}_${versionBuild_i686}_i686.tar.gz"; <del> sha256 = "03421s0k91c02ga9k6bdvixw71brlgi13q82cinnfayg3fhb0rb6"; </del> <ins> sha256 = "0k6dspmwdkm0zf0c2zqlqy0jya8qgsg90wwv9wa12fn4chp66gqg"; </ins> } else throw "NoMachine client is not supported on ${stdenv.hostPlatform.system}"; postUnpack = '' mv $(find . -type f -name nxclient.tar.gz) . mv $(find . -type f -name nxplayer.tar.gz) .


Question:
Describe the bug Installing nomachine-client fails To Reproduce Steps to reproduce the behavior: to environment.systemPackages Expected behavior It should build the derivation Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
I tried overriding the hash (any tip on how to more properly do this would be appreciated), but still got build errors in my under environment.systemPackages result:
There's a PR to upgrade : I this to my and it seems to be working for me:
Yep, this is because NoMachine removes each old release as soon as they make a new one. To combat this, I'll add to the sources list when the update is done.
I was finding at the time that even overriding with the latest URL and hash from the nomachine website, that it was failing to download the whole blob. I could do it from my browser, but it seemed to abort/not download the full size via nixos
Oh, that's strange.. Thankfully, it seems to work just fine now :)

tar xf nxplayer.tar.gz rm $(find . -maxdepth 1 -type f) ''; nativeBuildInputs = [ file makeWrapper autoPatchelfHook ]; buildInputs = [ jsoncpp libpulseaudio ];


Question:
Describe the bug Installing nomachine-client fails To Reproduce Steps to reproduce the behavior: to environment.systemPackages Expected behavior It should build the derivation Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
I tried overriding the hash (any tip on how to more properly do this would be appreciated), but still got build errors in my under environment.systemPackages result:
There's a PR to upgrade : I this to my and it seems to be working for me:
Yep, this is because NoMachine removes each old release as soon as they make a new one. To combat this, I'll add to the sources list when the update is done.
I was finding at the time that even overriding with the latest URL and hash from the nomachine website, that it was failing to download the whole blob. I could do it from my browser, but it seemed to abort/not download the full size via nixos
Oh, that's strange.. Thankfully, it seems to work just fine now :)

cp "$i"/* "$out/share/icons/hicolor/$(basename $i)/apps/" fi done mkdir $out/share/applications cp share/applnk/player/xdg/*.desktop $out/share/applications/ cp share/applnk/client/xdg-mime/*.desktop $out/share/applications/


Question:
Describe the bug Installing nomachine-client fails To Reproduce Steps to reproduce the behavior: to environment.systemPackages Expected behavior It should build the derivation Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
I tried overriding the hash (any tip on how to more properly do this would be appreciated), but still got build errors in my under environment.systemPackages result:
There's a PR to upgrade : I this to my and it seems to be working for me:
Yep, this is because NoMachine removes each old release as soon as they make a new one. To combat this, I'll add to the sources list when the update is done.
I was finding at the time that even overriding with the latest URL and hash from the nomachine website, that it was failing to download the whole blob. I could do it from my browser, but it seemed to abort/not download the full size via nixos
Oh, that's strange.. Thankfully, it seems to work just fine now :)

substituteInPlace "$i" --replace /usr/NX/bin $out/bin done ''; postFixup = '' makeWrapper $out/bin/nxplayer.bin $out/bin/nxplayer --set NX_SYSTEM $out/NX makeWrapper $out/bin/nxclient.bin $out/bin/nxclient --set NX_SYSTEM $out/NX


Question:
Describe the bug Installing nomachine-client fails To Reproduce Steps to reproduce the behavior: to environment.systemPackages Expected behavior It should build the derivation Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
I tried overriding the hash (any tip on how to more properly do this would be appreciated), but still got build errors in my under environment.systemPackages result:
There's a PR to upgrade : I this to my and it seems to be working for me:
Yep, this is because NoMachine removes each old release as soon as they make a new one. To combat this, I'll add to the sources list when the update is done.
I was finding at the time that even overriding with the latest URL and hash from the nomachine website, that it was failing to download the whole blob. I could do it from my browser, but it seemed to abort/not download the full size via nixos
Oh, that's strange.. Thankfully, it seems to work just fine now :)

# have a DT_NEEDED entry for it. patchelf --add-needed libpulse.so.0 $out/NX/lib/libnxcau.so ''; dontBuild = true; dontStrip = true;


Question:
Describe the bug Installing nomachine-client fails To Reproduce Steps to reproduce the behavior: to environment.systemPackages Expected behavior It should build the derivation Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
I tried overriding the hash (any tip on how to more properly do this would be appreciated), but still got build errors in my under environment.systemPackages result:
There's a PR to upgrade : I this to my and it seems to be working for me:
Yep, this is because NoMachine removes each old release as soon as they make a new one. To combat this, I'll add to the sources list when the update is done.
I was finding at the time that even overriding with the latest URL and hash from the nomachine website, that it was failing to download the whole blob. I could do it from my browser, but it seemed to abort/not download the full size via nixos
Oh, that's strange.. Thankfully, it seems to work just fine now :)

platforms = [ "x86_64-linux" "i686-linux" ]; }; }