Question:
Describe the bug On NixOS 20.09 and unstable, is not in the search path, even though it is installed with the php package. To Reproduce Steps to reproduce the behavior: [example from 20.09 system] Expected behavior [example from 20.03 system] Additional context Debugging with reveals that on 20.09, php is searching in , then , which fails. On 20.03, it searches in , then , which succeeds. On 20.09 and unstable, php74 and php73 both fail. On 20.03, php73 (the default) works, but php74 fails, but I believe it fails for a different reason. This line is new since release-20.03. At first glance, it seems as though is resolving to null here, but I'm not sure what to replace it with: Notify maintainers Metadata Maintainer information:
Thanks for reporting this issue! Your guess was right on spot and it was a really simple fix it seems :slightlysmilingface: As you may have seen: Right after 20.03 branched off we started a big refactoring of the PHP ecosystem. So bugs and issues was to be expected :slightlysmilingface:

++ lib.optional (!cgiSupport) "--disable-cgi" ++ lib.optional (!cliSupport) "--disable-cli" ++ lib.optional fpmSupport    "--enable-fpm" <del> ++ lib.optional pearSupport [ "--with-pear=$(out)/lib/php/pear" "--enable-xml" "--with-libxml" ] </del> <ins> ++ lib.optional pearSupport [ "--with-pear" "--enable-xml" "--with-libxml" ] </ins> ++ lib.optionals (pearSupport && (lib.versionOlder version "7.4")) [ "--enable-libxml" "--with-libxml-dir=${libxml2.dev}"


Question: I'm using the example of which renders correctly in firefox (the text in that section matches the image), but not in chromium (I see some placeholder boxes) my font configuration is exactly that given in I'm running nixos-unstable. I don't have flash enabled, or any other modifications to the default chromium package. From a bit of research, I've found that it might be the case that chromium restricts access to system fonts in some way, as a privacy aid - possibly that is to blame. Note: this occurs without any addons (running chromium as )

{stdenv, fetchurl}: stdenv.mkDerivation rec { <del> name = "ncompress-4.2.4.3"; </del> <ins> name = "ncompress-4.2.4.4"; </ins> builder = ./builder.sh;


Question: I'm using the example of which renders correctly in firefox (the text in that section matches the image), but not in chromium (I see some placeholder boxes) my font configuration is exactly that given in I'm running nixos-unstable. I don't have flash enabled, or any other modifications to the default chromium package. From a bit of research, I've found that it might be the case that chromium restricts access to system fonts in some way, as a privacy aid - possibly that is to blame. Note: this occurs without any addons (running chromium as )

src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {


Question:
Describe the bug When cinnamon is started either via gdm or in a . Sometimes the desktop icons do load Always a window spawns telling me that I'm in fallback mode no taskbar, no window decorations (hence I think no compositor & window manager) To Reproduce Here I'm kind of unsure: I deleted all nemo and cinnamon folder in $HOME, .config and .local/share. Still this occurs on all of my machines. IIRC this first happen when accidentally starting a "virtual keyboard" app cinnamon "Virtual keyboard" cinnamon components crash instantly, the and the behavior is reproducible on further attempts of starting cinnamon Expected behavior Cinnamon starts and is usable Additional context Booting into an old generation did not fix this, however, I'm quite unsure what could be the cause of it. This is some log which I could create by running cinnamon from a . I'm not sure whether this is related to the issue or not. relevant : Output captured (the log is over 2000 lines long, this is from the very end and might be the issue): Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(wucke13): nixpkgs: Maintainer information:
I will say that it does start in lightdm. IIRC upstream uses slick greeter and lightdm, so maybe it's just broken for that dm.
it is broken when started on as well, and it used to work in gdm just a day a go as well. Thinking more of the problem, what else can break the startup of cinnamon if all of these are empty/removed: + + + ? There must be something in my $HOME which alters the startup procedure of cinnamon to break (otherwise it wouldn't work for you?!) but what can it be? Edit: I now gathered a more meaningful error: Edit 2: Found the remaining part thing: dconf. After renaming , cinnamon starts just fine. Holy moly. Running "Virtual keyboard" from the cinnamon menu breaks it immediately, though.
Which package provides gio for ? We'd need to add that to buildInputs then the error should be fixed
That is . Be sure to on the source code to always run a to see what namespaces are imported. From there you track where those typelibs come from to determine the dependencies that belong in
Any updates on this?
It would need to be tested if the issue still persists.
The bug is still persistent. system: host os: multi-user?: sandbox: version: channels(root): channels(wucke13): nixpkgs:
The bug is still present in 21.05: system: host os: multi-user?: sandbox: version: channels(root): channels(wucke13): nixpkgs:
The main problem I have is that I have no idea where to even start debugging the segfault, as it seems to be part of native code
Any chances upstream has some idea? Not sure how to get in touch with them without making it seem like "We have a problem and you shall fix it".
I ran and I found that it is missing , just install it and the bug will disappear. I think this package is a must or we have a security-issue here
I can confirm installing caribou fixes the issue. I haven't really looked into it yet, the related line is likely at And I managed to SIGSEGV gjs-console (cjs-console) in a shell with: I search for the output , and found this So I do and the SIGSEGV is gone. So I guess caribou is needed for this case.

intltool gtk-doc perl <ins> python3.pkgs.wrapPython </ins> ]; # use locales from cinnamon-translations (not using --localedir because datadir is used)


Question:
Describe the bug When cinnamon is started either via gdm or in a . Sometimes the desktop icons do load Always a window spawns telling me that I'm in fallback mode no taskbar, no window decorations (hence I think no compositor & window manager) To Reproduce Here I'm kind of unsure: I deleted all nemo and cinnamon folder in $HOME, .config and .local/share. Still this occurs on all of my machines. IIRC this first happen when accidentally starting a "virtual keyboard" app cinnamon "Virtual keyboard" cinnamon components crash instantly, the and the behavior is reproducible on further attempts of starting cinnamon Expected behavior Cinnamon starts and is usable Additional context Booting into an old generation did not fix this, however, I'm quite unsure what could be the cause of it. This is some log which I could create by running cinnamon from a . I'm not sure whether this is related to the issue or not. relevant : Output captured (the log is over 2000 lines long, this is from the very end and might be the issue): Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(wucke13): nixpkgs: Maintainer information:
I will say that it does start in lightdm. IIRC upstream uses slick greeter and lightdm, so maybe it's just broken for that dm.
it is broken when started on as well, and it used to work in gdm just a day a go as well. Thinking more of the problem, what else can break the startup of cinnamon if all of these are empty/removed: + + + ? There must be something in my $HOME which alters the startup procedure of cinnamon to break (otherwise it wouldn't work for you?!) but what can it be? Edit: I now gathered a more meaningful error: Edit 2: Found the remaining part thing: dconf. After renaming , cinnamon starts just fine. Holy moly. Running "Virtual keyboard" from the cinnamon menu breaks it immediately, though.
Which package provides gio for ? We'd need to add that to buildInputs then the error should be fixed
That is . Be sure to on the source code to always run a to see what namespaces are imported. From there you track where those typelibs come from to determine the dependencies that belong in
Any updates on this?
It would need to be tested if the issue still persists.
The bug is still persistent. system: host os: multi-user?: sandbox: version: channels(root): channels(wucke13): nixpkgs:
The bug is still present in 21.05: system: host os: multi-user?: sandbox: version: channels(root): channels(wucke13): nixpkgs:
The main problem I have is that I have no idea where to even start debugging the segfault, as it seems to be part of native code
Any chances upstream has some idea? Not sure how to get in touch with them without making it seem like "We have a problem and you shall fix it".
I ran and I found that it is missing , just install it and the bug will disappear. I think this package is a must or we have a security-issue here
I can confirm installing caribou fixes the issue. I haven't really looked into it yet, the related line is likely at And I managed to SIGSEGV gjs-console (cjs-console) in a shell with: I search for the output , and found this So I do and the SIGSEGV is gone. So I guess caribou is needed for this case.

patchShebangs src/data-to-c.pl ''; <ins> preFixup = '' # https://github.com/NixOS/nixpkgs/issues/101881 gappsWrapperArgs+=( --prefix XDG_DATA_DIRS : "${gnome.caribou}/share" ) # https://github.com/NixOS/nixpkgs/issues/129946 buildPythonPath "${python3.pkgs.xapp}" patchPythonScript $out/share/cinnamon/cinnamon-desktop-editor/cinnamon-desktop-editor.py ''; </ins> passthru = { providedSessions = [ "cinnamon" "cinnamon2d" ]; };


Question: , CVSSv3=8.8 (nixos-20.03, nixos-20.09, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-20.09: ; nixos-unstable: . Cc

{ stdenv, fetchurl, pkgconfig, yasm <del> , freetype, fribidi </del> <ins> , freetype, fribidi, harfbuzz </ins> , encaSupport ? true, enca ? null # enca support , fontconfigSupport ? true, fontconfig ? null # fontconfig support <del> , harfbuzzSupport ? true, harfbuzz ? null # harfbuzz support </del> , rasterizerSupport ? false # Internal rasterizer , largeTilesSupport ? false # Use larger tiles in the rasterizer , libiconv


Question: , CVSSv3=8.8 (nixos-20.03, nixos-20.09, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-20.09: ; nixos-unstable: . Cc

assert encaSupport -> enca != null; assert fontconfigSupport -> fontconfig != null; <del> assert harfbuzzSupport -> harfbuzz != null; </del> let mkFlag = optSet: flag: if optSet then "--enable-${flag}" else "--disable-${flag}";


Question: , CVSSv3=8.8 (nixos-20.03, nixos-20.09, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-20.09: ; nixos-unstable: . Cc

with stdenv.lib; stdenv.mkDerivation rec { pname = "libass"; <del> version = "0.14.0"; </del> <ins> version = "0.15.0"; </ins> src = fetchurl { url = "https://github.com/libass/libass/releases/download/${version}/${pname}-${version}.tar.xz"; <del> sha256 = "18iqznl4mabhj9ywfsz4kwvbsplcv1jjxq50nxssvbj8my1267w8"; </del> <ins> sha256 = "0cz8v6kh3f2j5rdjrra2z0h715fa16vjm7kambvqx9hak86262cz"; </ins> }; configureFlags = [ (mkFlag encaSupport "enca") (mkFlag fontconfigSupport "fontconfig") <del> (mkFlag harfbuzzSupport "harfbuzz") </del> (mkFlag rasterizerSupport "rasterizer") (mkFlag largeTilesSupport "large-tiles") ]; nativeBuildInputs = [ pkgconfig yasm ]; <del> buildInputs = [ freetype fribidi ] </del> <ins> buildInputs = [ freetype fribidi harfbuzz ] </ins> ++ optional encaSupport enca ++ optional fontconfigSupport fontconfig <del> ++ optional harfbuzzSupport harfbuzz </del> ++ optional stdenv.isDarwin libiconv; meta = {


Question:
With NixOS 15.09 I get this error running LilyPond: I can work around this (clumsily) by using an old version of in LilyPond's . This differs by not including . This seems to be related to Changing apparently can break some users of as well as those of .
cc
Hmm, perhaps we should add or some similar option to handle these cases easily?
It's better to set in most cases, which I just did in and .


Question:
With NixOS 15.09 I get this error running LilyPond: I can work around this (clumsily) by using an old version of in LilyPond's . This differs by not including . This seems to be related to Changing apparently can break some users of as well as those of .
cc
Hmm, perhaps we should add or some similar option to handle these cases easily?
It's better to set in most cases, which I just did in and .


Question: Describe the bug defines the CMake path. The environment variable is included in this, and addons like SDL2mixer append themselves to this path. However, that same file also defines an target, which does not include in its include directories. See for an example of an issue caused by this. To Reproduce Steps to reproduce the behavior: to build an application relying on SDL2::SDL2 adding SDL2mixer to the include path, such as Expected behavior 's should include the environment variable, just like . Screenshots N/A Additional context N/A Notify maintainers (SDL2), (SDL2mixer) Metadata Maintainer information:

<del> diff -ru3 SDL2-2.0.4/sdl2-config.cmake.in SDL2-2.0.4-new/sdl2-config.cmake.in --- SDL2-2.0.4/sdl2-config.cmake.in	2016-01-02 22:56:31.000000000 +0300 +++ SDL2-2.0.4-new/sdl2-config.cmake.in	2016-08-22 05:26:42.420397323 +0300 @@ -6,5 +6,6 @@ </del> <ins> diff -ru3 SDL2-2.0.12/sdl2-config.cmake.in SDL2-2.0.12-new/sdl2-config.cmake.in --- SDL2-2.0.12/sdl2-config.cmake.in	2020-03-11 02:36:18.000000000 +0100 +++ SDL2-2.0.12-new/sdl2-config.cmake.in	2020-11-11 11:59:05.178703826 +0100 @@ -6,7 +6,8 @@ </ins> set(SDL2_PREFIX "@prefix@") set(SDL2_EXEC_PREFIX "@prefix@") set(SDL2_LIBDIR "@libdir@")


Question: Describe the bug defines the CMake path. The environment variable is included in this, and addons like SDL2mixer append themselves to this path. However, that same file also defines an target, which does not include in its include directories. See for an example of an issue caused by this. To Reproduce Steps to reproduce the behavior: to build an application relying on SDL2::SDL2 adding SDL2mixer to the include path, such as Expected behavior 's should include the environment variable, just like . Screenshots N/A Additional context N/A Notify maintainers (SDL2), (SDL2mixer) Metadata Maintainer information:

+set(SDL2_INCLUDE_DIRS "@includedir@/SDL2" $ENV{SDL2_PATH}) +separate_arguments(SDL2_INCLUDE_DIRS) set(SDL2_LIBRARIES "-L${SDL2_LIBDIR} @SDL_RLD_FLAGS@ @SDL_LIBS@") <del> diff -ru3 SDL2-2.0.4/sdl2-config.in SDL2-2.0.4-new/sdl2-config.in --- SDL2-2.0.4/sdl2-config.in	2016-01-02 22:56:31.000000000 +0300 +++ SDL2-2.0.4-new/sdl2-config.in	2016-08-22 05:32:02.256397839 +0300 </del> <ins> string(STRIP "${SDL2_LIBRARIES}" SDL2_LIBRARIES) @@ -20,14 +21,14 @@ add_library(SDL2::SDL2 SHARED IMPORTED) set_target_properties(SDL2::SDL2 PROPERTIES -    INTERFACE_INCLUDE_DIRECTORIES "@includedir@/SDL2" +    INTERFACE_INCLUDE_DIRECTORIES "${SDL2_INCLUDE_DIRS}" IMPORTED_LINK_INTERFACE_LANGUAGES "C" IMPORTED_LOCATION "@libdir@/libSDL2.so" INTERFACE_LINK_LIBRARIES "${SDL2_EXTRA_LINK_FLAGS}") add_library(SDL2::SDL2-static STATIC IMPORTED) set_target_properties(SDL2::SDL2-static PROPERTIES -    INTERFACE_INCLUDE_DIRECTORIES "@includedir@/SDL2" +    INTERFACE_INCLUDE_DIRECTORIES "${SDL2_INCLUDE_DIRS}" IMPORTED_LINK_INTERFACE_LANGUAGES "C" IMPORTED_LOCATION "@libdir@/libSDL2.a" INTERFACE_LINK_LIBRARIES "${SDL2_EXTRA_LINK_FLAGS_STATIC}") Només a SDL2-2.0.12-new/: sdl2-config.cmake.in.orig diff -ru3 SDL2-2.0.12/sdl2-config.in SDL2-2.0.12-new/sdl2-config.in --- SDL2-2.0.12/sdl2-config.in	2020-03-11 02:36:18.000000000 +0100 +++ SDL2-2.0.12-new/sdl2-config.in	2020-11-11 11:56:26.432955479 +0100 </ins> @@ -42,7 +42,11 @@ echo @SDL_VERSION@ ;;


Question:
Experienced on gnome3.38 which is currently on master. alacritty 0.5.0 isn't functional at all. 0.6.0rc-1 is. Should we update in order to make our packages set functional? Or should we wait for a real, no rc release upstream?
you should update yourself in the maintainers list - I had to go to to see who is .
Is this a wayland issue on gnome?
Yes.
Sound fine to me.
Thanks for pointing this out. As much as I want to see my first username long gone, the change was not worth it :)

in rustPlatform.buildRustPackage rec { pname = "alacritty"; <del> version = "0.5.0"; </del> <ins> # 0.5.0 is not compatible with gnome 3.38 version = "0.6.0-rc1"; </ins> src = fetchFromGitHub { owner = "alacritty"; repo = pname; rev = "v${version}"; <del> sha256 = "1948j57xhqvc5y876s929x9rhd6j0xnw5c91g1zqw2rfncn602g2"; </del> <ins> sha256 = "RuIJvB0J/BQFqemOkEUiqS1uz0gMS49Dd8UQt0nbrQ0="; </ins> }; <del> cargoSha256 = "17lyzcj07f0vyki3091vgjd0w8ki11sw5m8gb3bxdph1dl04rria"; </del> <ins> cargoSha256 = "+3iZywLvy+8C7j6g9bqij2DSLjBoE2u1GXgfV04cWRY="; </ins> nativeBuildInputs = [ cmake


Question:
Updated using I though most of the packages have moved on to openblas, what is pulling in this package? How would I find out?
A few packages still reference it. should show what derivations use it directly, from those you have instantiated.


Question:
Updated using I though most of the packages have moved on to openblas, what is pulling in this package? How would I find out?
A few packages still reference it. should show what derivations use it directly, from those you have instantiated.


Question:
Describe the bug option is not working To Reproduce Steps to reproduce the behavior: service and its option in . Add as well for testing. In my case I used something similar to the password read bit is set, for the test generation: (eventually) inspect logs with in a separate terminal a mail The command might return And you might find an error similar to this in your logs Tested on 19.09 and 20.09, on different machines with three different SMTP hosts, various passwords, with and without special characters. As explicitly warn in the doc Path to a file that contains the password used for SMTP auth. The file should not contain a trailing newline, if the password does not contain one. This file should be readable by the users that need to execute ssmtp. I ensured that the password do not contains a leading space or carriage return. Expected behavior should work just as well as its former obsolete attribute. Additional context eventually check again my password in the store: which is yet followed by the character . It's obviously a control character and I cannot find a definition of its meaning. The very same command (original pass file) won't return the . following configuration works, with of course the exact same password as provided in the password file. Which is obviously not the expected setup. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Make sure that it doesn't have a trailing either. Editors like vim tend to insert one by default.
I can confirm.
Is this still a problem?
I haven't been able to validate the response using or alternative editors.
Use to avoid the trailing newline. To check whether there's one, use ; with this command, newlines are displayed as .

example = "/run/keys/ssmtp-authpass"; description = '' Path to a file that contains the password used for SMTP auth. The file <del> should not contain a trailing newline, if the password does not contain one. </del> <ins> should not contain a trailing newline, if the password does not contain one (e.g. use <command>echo -n "password" > file</command>). </ins> This file should be readable by the users that need to execute ssmtp. ''; };


Question:
Seems like nmap changed the licence with the 7.90 release from GPL-2 to NPSL (Nmap public source licence). NPSL is "based" on GPL but adds some nasty things such as: Which conflicts with the freedom 0: Discussions about this: Debian: Gentoo: Upstream: The actual license file: They also seem to bundle a GPL library, and their license doesn't seem to be GPL compatible. So we should probably add this new license at least. NPSL looks non-free to me. Non-free is a good default until FSF or anyone has looked at it. We can always follow suit with what Debian does as well.
Another option would be to revert to 7.80 for now. The new license seems to be a legal minefield even if you're ok with closed source.
Yeah while looking at the issue in the train I thought of the same as well, will do that now.
I just read the release annoncement for 7.90: Just to see if the license change was mentioned there. Which it is: Do I read this right they weren't really GPLv2 to begin with and just clarified that? That's like a major thing...
First of all I just realized that I merged the original PR, so I really have to apologize for missing that license thing back then! cc in case you currently have time and energy for that, would you mind taking a look at the issue? I'm pretty sure that you have way more knowledge and insights about that kind of licensing issue than we have :). Is there any kind of statement from OSI or FSF yet? Also, I'm wondering if other distros that are even more focused on free software than we are (such as Guix) have e.g. started a new fork that we may want to use as well.
More details from the changelog: I must say that I'm not sure if it's worth to roll the package back since it actually haven't seemed to change really. It just was weird to begin with and just now got a name on the weirdness.
It's not just a new name, apparently they also new requirements in 7.90:
I don't think we should revert it either. Add the new license and mark it unfree until this is clarified.
Oof.... that's actually another reason for reverting.
I'm in favor of marking as nonfree until the FSF or some other authoritative organisation decides otherwise.
Either revert, or mark as non-free. Or, revert and add the new, non-free, version next to it.
The nmap update has already been reverted. Let's wait what upstream and the legal teams of debian/fedora say. See also the upstream issue
Fedora's stance
That's the old license (until version 7.80). This issue is about the new license (in version 7.90).
Fedora the new licence to the bad list and marked it as "not acceptable for use in Fedora" due to being incompatible to the open source definition
So, now there's an update here that we may want to act on: To quote the post: This means that 7.91 is now available under the same license as 7.80 is. The license that 7.80 uses is still a "bad license" because it's still a custom license. But it's a license that we and other distributions have considered good because it was assumed to be GPLv2. So I'm thinking that we could upgrade to 7.91 by now, because it's still not good, but it's not worse than before except we are aware of it now. Then we just hope that they do some good re-licensing in a future release.
Merged which removed nmap-unfree. This issue is done for now. Thanks everyone.

stdenv.mkDerivation rec { name = "nmap${optionalString graphicalSupport "-graphical"}-${version}"; <del> version = "7.90"; </del> <ins> version = "7.80"; </ins> src = fetchurl { url = "https://nmap.org/dist/nmap-${version}.tar.bz2"; <del> sha256 = "1s20i84m9bci70lrl0p2j7h3kpbi9snmvyhc3lzc9s3mh92w6msm"; </del> <ins> sha256 = "1aizfys6l9f9grm82bk878w56mg0zpkfns3spzj157h98875mypw"; </ins> }; patches = [ ./zenmap.patch ]


Question:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)

<para> This chapter describes tools for creating various types of images. </para> <del> <xi:include href="images/appimagetools.xml" /> </del> <ins> <xi:include href="images/appimagetools.section.xml" /> </ins> <xi:include href="images/dockertools.section.xml" /> <xi:include href="images/ocitools.section.xml" /> <del> <xi:include href="images/snaptools.xml" /> </del> <ins> <xi:include href="images/snaptools.section.xml" /> </ins> </chapter>


Question:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)

<ins> # pkgs.appimageTools {#sec-pkgs-appimageTools} `pkgs.appimageTools` is a set of functions for extracting and wrapping [AppImage](https://appimage.org/) files. They are meant to be used if traditional packaging from source is infeasible, or it would take too long. To quickly run an AppImage file, `pkgs.appimage-run` can be used as well. ::: warning The `appimageTools` API is unstable and may be subject to backwards-incompatible changes in the future. ::: ## AppImage formats {#ssec-pkgs-appimageTools-formats} There are different formats for AppImages, see [the specification](https://github.com/AppImage/AppImageSpec/blob/74ad9ca2f94bf864a4a0dac1f369dd4f00bd1c28/draft.md#image-format) for details. - Type 1 images are ISO 9660 files that are also ELF executables. - Type 2 images are ELF executables with an appended filesystem. They can be told apart with `file -k`: ```ShellSession $ file -k type1.AppImage type1.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) ISO 9660 CD-ROM filesystem data 'AppImage' (Lepton 3.x), scale 0-0, spot sensor temperature 0.000000, unit celsius, color scheme 0, calibration: offset 0.000000, slope 0.000000, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=d629f6099d2344ad82818172add1d38c5e11bc6d, stripped012- data $ file -k type2.AppImage type2.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) (Lepton 3.x), scale 232-60668, spot sensor temperature -4.187500, color scheme 15, show scale bar, calibration: offset -0.000000, slope 0.000000 (Lepton 2.x), scale 4111-45000, spot sensor temperature 412442.250000, color scheme 3, minimum point enabled, calibration: offset -75402534979642766821519867692934234112.000000, slope 5815371847733706829839455140374904832.000000, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=79dcc4e55a61c293c5e19edbd8d65b202842579f, stripped012- data ``` Note how the type 1 AppImage is described as an `ISO 9660 CD-ROM filesystem`, and the type 2 AppImage is not. ## Wrapping {#ssec-pkgs-appimageTools-wrapping} Depending on the type of AppImage you're wrapping, you'll have to use `wrapType1` or `wrapType2`. ```nix appimageTools.wrapType2 { # or wrapType1 name = "patchwork"; src = fetchurl { url = "https://github.com/ssbc/patchwork/releases/download/v3.11.4/Patchwork-3.11.4-linux-x86_64.AppImage"; sha256 = "1blsprpkvm0ws9b96gb36f0rbf8f5jgmw4x6dsb1kswr4ysf591s"; }; extraPkgs = pkgs: with pkgs; [ ]; } ``` - `name` specifies the name of the resulting image. - `src` specifies the AppImage file to extract. - `extraPkgs` allows you to pass a function to include additional packages inside the FHS environment your AppImage is going to run in. There are a few ways to learn which dependencies an application needs: - Looking through the extracted AppImage files, reading its scripts and running `patchelf` and `ldd` on its executables. This can also be done in `appimage-run`, by setting `APPIMAGE_DEBUG_EXEC=bash`. - Running `strace -vfefile` on the wrapped executable, looking for libraries that can't be found. </ins>


Question:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)

<del> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xi="http://www.w3.org/2001/XInclude" xml:id="sec-pkgs-appimageTools"> <title>pkgs.appimageTools</title> <para> <varname>pkgs.appimageTools</varname> is a set of functions for extracting and wrapping <link xlink:href="https://appimage.org/">AppImage</link> files. They are meant to be used if traditional packaging from source is infeasible, or it would take too long. To quickly run an AppImage file, <literal>pkgs.appimage-run</literal> can be used as well. </para> <warning> <para> The <varname>appimageTools</varname> API is unstable and may be subject to backwards-incompatible changes in the future. </para> </warning> <section xml:id="ssec-pkgs-appimageTools-formats"> <title>AppImage formats</title> <para> There are different formats for AppImages, see <link xlink:href="https://github.com/AppImage/AppImageSpec/blob/74ad9ca2f94bf864a4a0dac1f369dd4f00bd1c28/draft.md#image-format">the specification</link> for details. </para> <itemizedlist> <listitem> <para> Type 1 images are ISO 9660 files that are also ELF executables. </para> </listitem> <listitem> <para> Type 2 images are ELF executables with an appended filesystem. </para> </listitem> </itemizedlist> <para> They can be told apart with <command>file -k</command>: </para> <screen> <prompt>$ </prompt>file -k type1.AppImage type1.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) ISO 9660 CD-ROM filesystem data 'AppImage' (Lepton 3.x), scale 0-0, spot sensor temperature 0.000000, unit celsius, color scheme 0, calibration: offset 0.000000, slope 0.000000, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=d629f6099d2344ad82818172add1d38c5e11bc6d, stripped012- data <prompt>$ </prompt>file -k type2.AppImage type2.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) (Lepton 3.x), scale 232-60668, spot sensor temperature -4.187500, color scheme 15, show scale bar, calibration: offset -0.000000, slope 0.000000 (Lepton 2.x), scale 4111-45000, spot sensor temperature 412442.250000, color scheme 3, minimum point enabled, calibration: offset -75402534979642766821519867692934234112.000000, slope 5815371847733706829839455140374904832.000000, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=79dcc4e55a61c293c5e19edbd8d65b202842579f, stripped012- data </screen> <para> Note how the type 1 AppImage is described as an <literal>ISO 9660 CD-ROM filesystem</literal>, and the type 2 AppImage is not. </para> </section> <section xml:id="ssec-pkgs-appimageTools-wrapping"> <title>Wrapping</title> <para> Depending on the type of AppImage you're wrapping, you'll have to use <varname>wrapType1</varname> or <varname>wrapType2</varname>. </para> <programlisting> appimageTools.wrapType2 { # or wrapType1 name = "patchwork"; <co xml:id='ex-appimageTools-wrapping-1' /> src = fetchurl { <co xml:id='ex-appimageTools-wrapping-2' /> url = "https://github.com/ssbc/patchwork/releases/download/v3.11.4/Patchwork-3.11.4-linux-x86_64.AppImage"; sha256 =  "1blsprpkvm0ws9b96gb36f0rbf8f5jgmw4x6dsb1kswr4ysf591s"; }; extraPkgs = pkgs: with pkgs; [ ]; <co xml:id='ex-appimageTools-wrapping-3' /> }</programlisting> <calloutlist> <callout arearefs='ex-appimageTools-wrapping-1'> <para> <varname>name</varname> specifies the name of the resulting image. </para> </callout> <callout arearefs='ex-appimageTools-wrapping-2'> <para> <varname>src</varname> specifies the AppImage file to extract. </para> </callout> <callout arearefs='ex-appimageTools-wrapping-3'> <para> <varname>extraPkgs</varname> allows you to pass a function to include additional packages inside the FHS environment your AppImage is going to run in. There are a few ways to learn which dependencies an application needs: <itemizedlist> <listitem> <para> Looking through the extracted AppImage files, reading its scripts and running <command>patchelf</command> and <command>ldd</command> on its executables. This can also be done in <command>appimage-run</command>, by setting <command>APPIMAGE_DEBUG_EXEC=bash</command>. </para> </listitem> <listitem> <para> Running <command>strace -vfefile</command> on the wrapped executable, looking for libraries that can't be found. </para> </listitem> </itemizedlist> </para> </callout> </calloutlist> </section> </section> </del>


Question:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)

<del> let inherit (import <nixpkgs> { }) snapTools firefox; in snapTools.makeSnap { meta = { name = "nix-example-firefox"; summary = firefox.meta.description; architectures = [ "amd64" ]; apps.nix-example-firefox = { command = "${firefox}/bin/firefox"; plugs = [ "pulseaudio" "camera" "browser-support" "avahi-observe" "cups-control" "desktop" "desktop-legacy" "gsettings" "home" "network" "mount-observe" "removable-media" "x11" ]; }; confinement = "strict"; }; } </del>


Question:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)

<del> let inherit (import <nixpkgs> { }) snapTools hello; in snapTools.makeSnap { meta = { name = "hello"; summary = hello.meta.description; description = hello.meta.longDescription; architectures = [ "amd64" ]; confinement = "strict"; apps.hello.command = "${hello}/bin/hello"; }; } </del>


Question:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)

<ins> # pkgs.snapTools {#sec-pkgs-snapTools} `pkgs.snapTools` is a set of functions for creating Snapcraft images. Snap and Snapcraft is not used to perform these operations. ## The makeSnap Function {#ssec-pkgs-snapTools-makeSnap-signature} `makeSnap` takes a single named argument, `meta`. This argument mirrors [the upstream `snap.yaml` format](https://docs.snapcraft.io/snap-format) exactly. The `base` should not be specified, as `makeSnap` will force set it. Currently, `makeSnap` does not support creating GUI stubs. ## Build a Hello World Snap {#ssec-pkgs-snapTools-build-a-snap-hello} The following expression packages GNU Hello as a Snapcraft snap. ```{#ex-snapTools-buildSnap-hello .nix} let inherit (import <nixpkgs> { }) snapTools hello; in snapTools.makeSnap { meta = { name = "hello"; summary = hello.meta.description; description = hello.meta.longDescription; architectures = [ "amd64" ]; confinement = "strict"; apps.hello.command = "${hello}/bin/hello"; }; } ``` `nix-build` this expression and install it with `snap install ./result --dangerous`. `hello` will now be the Snapcraft version of the package. ## Build a Graphical Snap {#ssec-pkgs-snapTools-build-a-snap-firefox} Graphical programs require many more integrations with the host. This example uses Firefox as an example, because it is one of the most complicated programs we could package. ```{#ex-snapTools-buildSnap-firefox .nix} let inherit (import <nixpkgs> { }) snapTools firefox; in snapTools.makeSnap { meta = { name = "nix-example-firefox"; summary = firefox.meta.description; architectures = [ "amd64" ]; apps.nix-example-firefox = { command = "${firefox}/bin/firefox"; plugs = [ "pulseaudio" "camera" "browser-support" "avahi-observe" "cups-control" "desktop" "desktop-legacy" "gsettings" "home" "network" "mount-observe" "removable-media" "x11" ]; }; confinement = "strict"; }; } ``` `nix-build` this expression and install it with `snap install ./result --dangerous`. `nix-example-firefox` will now be the Snapcraft version of the Firefox package. The specific meaning behind plugs can be looked up in the [Snapcraft interface documentation](https://docs.snapcraft.io/supported-interfaces). </ins>


Question:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)

<del> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xi="http://www.w3.org/2001/XInclude" xml:id="sec-pkgs-snapTools"> <title>pkgs.snapTools</title> <para> <varname>pkgs.snapTools</varname> is a set of functions for creating Snapcraft images. Snap and Snapcraft is not used to perform these operations. </para> <section xml:id="ssec-pkgs-snapTools-makeSnap-signature"> <title>The makeSnap Function</title> <para> <function>makeSnap</function> takes a single named argument, <parameter>meta</parameter>. This argument mirrors <link xlink:href="https://docs.snapcraft.io/snap-format">the upstream <filename>snap.yaml</filename> format</link> exactly. </para> <para> The <parameter>base</parameter> should not be specified, as <function>makeSnap</function> will force set it. </para> <para> Currently, <function>makeSnap</function> does not support creating GUI stubs. </para> </section> <section xml:id="ssec-pkgs-snapTools-build-a-snap-hello"> <title>Build a Hello World Snap</title> <example xml:id="ex-snapTools-buildSnap-hello"> <title>Making a Hello World Snap</title> <para> The following expression packages GNU Hello as a Snapcraft snap. </para> <programlisting><xi:include href="./snap/example-hello.nix" parse="text" /></programlisting> <para> <command>nix-build</command> this expression and install it with <command>snap install ./result --dangerous</command>. <command>hello</command> will now be the Snapcraft version of the package. </para> </example> </section> <section xml:id="ssec-pkgs-snapTools-build-a-snap-firefox"> <title>Build a Hello World Snap</title> <example xml:id="ex-snapTools-buildSnap-firefox"> <title>Making a Graphical Snap</title> <para> Graphical programs require many more integrations with the host. This example uses Firefox as an example, because it is one of the most complicated programs we could package. </para> <programlisting><xi:include href="./snap/example-firefox.nix" parse="text" /></programlisting> <para> <command>nix-build</command> this expression and install it with <command>snap install ./result --dangerous</command>. <command>nix-example-firefox</command> will now be the Snapcraft version of the Firefox package. </para> <para> The specific meaning behind plugs can be looked up in the <link xlink:href="https://docs.snapcraft.io/supported-interfaces">Snapcraft interface documentation</link>. </para> </example> </section> </section> </del>


Question: This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.


Question: This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.


Question: This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.


Question: This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.


Question: This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.


Question: This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.


Question: This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.


Question: Describe the bug Milkytracker is missing a menu entry to launch the application Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --

# Somehow this does not get set automatically cmakeFlags = [ "-DSDL2MAIN_LIBRARY=${SDL2}/lib/libSDL2.so" ]; <ins> postInstall = '' install -Dm644 $src/resources/milkytracker.desktop $out/share/applications/milkytracker.desktop install -Dm644 $src/resources/pictures/carton.png $out/share/pixmaps/milkytracker.png install -Dm644 $src/resources/milkytracker.appdata $out/share/appdata/milkytracker.appdata.xml ''; </ins> meta = with stdenv.lib; { description = "Music tracker application, similar to Fasttracker II"; homepage = "http://milkytracker.org";


Question: We should replace the discontinued source with the more active fork . wrecker/stern hasn't received any commits since 2019. The maintainer of stern doesn't work at wercker anymore, and it seems no one else there is maintaining it (wercker/stern). The community has since moved to stern/stern with improvements to the original source. Project description Multi pod and container log tailing for Kubernetes Metadata homepage URL: source URL: license: Apache-2.0 platforms: unix

<del> { stdenv, lib, buildPackages, buildGoPackage, fetchFromGitHub, installShellFiles }: </del> <ins> { stdenv, lib, buildPackages, buildGoModule, fetchFromGitHub, installShellFiles }: let isCrossBuild = stdenv.hostPlatform != stdenv.buildPlatform; </ins> <del> let isCrossBuild = stdenv.hostPlatform != stdenv.buildPlatform; in buildGoPackage rec { </del> <ins> in buildGoModule rec { </ins> pname = "stern"; <del> version = "1.11.0"; goPackagePath = "github.com/wercker/stern"; </del> <ins> version = "1.13.1"; </ins> src = fetchFromGitHub { <del> owner = "wercker"; </del> <ins> owner = "stern"; </ins> repo = "stern"; <del> rev = version; sha256 = "0xndlq0ks8flzx6rdd4lnkxpkbvdy9sj1jwys5yj7p989ls8by3n"; </del> <ins> rev = "v${version}"; sha256 = "0fj6a52wb0jv5bz2j2wq3ljnlxnsj9bg3kbzgkz0vh0b63zyn782"; </ins> }; <del> deleteVendor = true; goDeps = ./deps.nix; </del> <ins> vendorSha256 = "14nrdaaby74bjbk777hr82p0ybzk3spc59lbrjn9z0q3hc0p4vaf"; </ins> nativeBuildInputs = [ installShellFiles ]; <ins> buildFlagsArray = [ "-ldflags=-s -w -X github.com/stern/stern/cmd.version=${version}" ]; </ins> postInstall = <del> let stern = if isCrossBuild then buildPackages.stern else "$out"; in </del> <ins> let stern = if isCrossBuild then buildPackages.stern else "$out"; in </ins> '' for shell in bash zsh; do ${stern}/bin/stern --completion $shell > stern.$shell


Question: We should replace the discontinued source with the more active fork . wrecker/stern hasn't received any commits since 2019. The maintainer of stern doesn't work at wercker anymore, and it seems no one else there is maintaining it (wercker/stern). The community has since moved to stern/stern with improvements to the original source. Project description Multi pod and container log tailing for Kubernetes Metadata homepage URL: source URL: license: Apache-2.0 platforms: unix

''; meta = with lib; { <del> description      = "Multi pod and container log tailing for Kubernetes"; homepage         = "https://github.com/wercker/stern"; license          = licenses.asl20; maintainers      = with maintainers; [ mbode ]; platforms        = platforms.unix; </del> <ins> description = "Multi pod and container log tailing for Kubernetes"; homepage = "https://github.com/stern/stern"; license = licenses.asl20; maintainers = with maintainers; [ mbode preisschild ]; platforms = platforms.unix; </ins> }; }


Question: We should replace the discontinued source with the more active fork . wrecker/stern hasn't received any commits since 2019. The maintainer of stern doesn't work at wercker anymore, and it seems no one else there is maintaining it (wercker/stern). The community has since moved to stern/stern with improvements to the original source. Project description Multi pod and container log tailing for Kubernetes Metadata homepage URL: source URL: license: Apache-2.0 platforms: unix

<del> # file generated from Gopkg.lock using dep2nix (https://github.com/nixcloud/dep2nix) [ { goPackagePath  = "cloud.google.com/go"; fetch = { type = "git"; url = "https://code.googlesource.com/gocloud"; rev =  "dfffe386c33fb24c34ee501e5723df5b97b98514"; sha256 = "1g681yxz4mmzapzpzxfaz1nhcr1w526793yapfsnxlbs2skap3fy"; }; } { goPackagePath  = "github.com/Azure/go-autorest"; fetch = { type = "git"; url = "https://github.com/Azure/go-autorest"; rev =  "1ff28809256a84bb6966640ff3d0371af82ccba4"; sha256 = "0sxvj2j1833bqwxvhq3wq3jgq73rnb81pnzvl0x3y1m0hzpaf2zv"; }; } { goPackagePath  = "github.com/dgrijalva/jwt-go"; fetch = { type = "git"; url = "https://github.com/dgrijalva/jwt-go"; rev =  "06ea1031745cb8b3dab3f6a236daf2b0aa468b7e"; sha256 = "08m27vlms74pfy5z79w67f9lk9zkx6a9jd68k3c4msxy75ry36mp"; }; } { goPackagePath  = "github.com/fatih/color"; fetch = { type = "git"; url = "https://github.com/fatih/color"; rev =  "2d684516a8861da43017284349b7e303e809ac21"; sha256 = "1fcfmz4wji3gqmmsdx493r7d101s58hwjalqps6hy25nva5pvmfs"; }; } { goPackagePath  = "github.com/ghodss/yaml"; fetch = { type = "git"; url = "https://github.com/ghodss/yaml"; rev =  "73d445a93680fa1a78ae23a5839bad48f32ba1ee"; sha256 = "0pg53ky4sy3sp9j4n7vgf1p3gw4nbckwqfldcmmi9rf13kjh0mr7"; }; } { goPackagePath  = "github.com/gogo/protobuf"; fetch = { type = "git"; url = "https://github.com/gogo/protobuf"; rev =  "c0656edd0d9eab7c66d1eb0c568f9039345796f7"; sha256 = "0b943dhx571lhgcs3rqzy0092mi2x5mwy2kl7g8rryhy3r5rzrz9"; }; } { goPackagePath  = "github.com/golang/glog"; fetch = { type = "git"; url = "https://github.com/golang/glog"; rev =  "23def4e6c14b4da8ac2ed8007337bc5eb5007998"; sha256 = "0jb2834rw5sykfr937fxi8hxi2zy80sj2bdn9b3jb4b26ksqng30"; }; } { goPackagePath  = "github.com/golang/protobuf"; fetch = { type = "git"; url = "https://github.com/golang/protobuf"; rev =  "b4deda0973fb4c70b50d226b1af49f3da59f5265"; sha256 = "0ya4ha7m20bw048m1159ppqzlvda4x0vdprlbk5sdgmy74h3xcdq"; }; } { goPackagePath  = "github.com/google/btree"; fetch = { type = "git"; url = "https://github.com/google/btree"; rev =  "4030bb1f1f0c35b30ca7009e9ebd06849dd45306"; sha256 = "0ba430m9fbnagacp57krgidsyrgp3ycw5r7dj71brgp5r52g82p6"; }; } { goPackagePath  = "github.com/google/gofuzz"; fetch = { type = "git"; url = "https://github.com/google/gofuzz"; rev =  "24818f796faf91cd76ec7bddd72458fbced7a6c1"; sha256 = "0cq90m2lgalrdfrwwyycrrmn785rgnxa3l3vp9yxkvnv88bymmlm"; }; } { goPackagePath  = "github.com/googleapis/gnostic"; fetch = { type = "git"; url = "https://github.com/googleapis/gnostic"; rev =  "0c5108395e2debce0d731cf0287ddf7242066aba"; sha256 = "0jf3cp5clli88gpjf24r6wxbkvngnc1kf59d4cgjczsn2wasvsfc"; }; } { goPackagePath  = "github.com/gregjones/httpcache"; fetch = { type = "git"; url = "https://github.com/gregjones/httpcache"; rev =  "787624de3eb7bd915c329cba748687a3b22666a6"; sha256 = "1zqlg9pkj7r6fqw7wv3ywvbz3bh0hvzifs2scgcraj812q5189w5"; }; } { goPackagePath  = "github.com/imdario/mergo"; fetch = { type = "git"; url = "https://github.com/imdario/mergo"; rev =  "6633656539c1639d9d78127b7d47c622b5d7b6dc"; sha256 = "1fffbq1l17i0gynmvcxypl7d9h4v81g5vlimiph5bfgf4sp4db7g"; }; } { goPackagePath  = "github.com/inconshreveable/mousetrap"; fetch = { type = "git"; url = "https://github.com/inconshreveable/mousetrap"; rev =  "76626ae9c91c4f2a10f34cad8ce83ea42c93bb75"; sha256 = "1mn0kg48xkd74brf48qf5hzp0bc6g8cf5a77w895rl3qnlpfw152"; }; } { goPackagePath  = "github.com/json-iterator/go"; fetch = { type = "git"; url = "https://github.com/json-iterator/go"; rev =  "f2b4162afba35581b6d4a50d3b8f34e33c144682"; sha256 = "0siqfghsm2lkdwinvg8x5gls3p76rq3cdm59c1r4x0b2mdfhnvcd"; }; } { goPackagePath  = "github.com/mattn/go-colorable"; fetch = { type = "git"; url = "https://github.com/mattn/go-colorable"; rev =  "167de6bfdfba052fa6b2d3664c8f5272e23c9072"; sha256 = "1nwjmsppsjicr7anq8na6md7b1z84l9ppnlr045hhxjvbkqwalvx"; }; } { goPackagePath  = "github.com/mattn/go-isatty"; fetch = { type = "git"; url = "https://github.com/mattn/go-isatty"; rev =  "6ca4dbf54d38eea1a992b3c722a76a5d1c4cb25c"; sha256 = "0zs92j2cqaw9j8qx1sdxpv3ap0rgbs0vrvi72m40mg8aa36gd39w"; }; } { goPackagePath  = "github.com/mitchellh/go-homedir"; fetch = { type = "git"; url = "https://github.com/mitchellh/go-homedir"; rev =  "b8bc1bf767474819792c23f32d8286a45736f1c6"; sha256 = "13ry4lylalkh4g2vny9cxwvryslzyzwp9r92z0b10idhdq3wad1q"; }; } { goPackagePath  = "github.com/modern-go/concurrent"; fetch = { type = "git"; url = "https://github.com/modern-go/concurrent"; rev =  "bacd9c7ef1dd9b15be4a9909b8ac7a4e313eec94"; sha256 = "0s0fxccsyb8icjmiym5k7prcqx36hvgdwl588y0491gi18k5i4zs"; }; } { goPackagePath  = "github.com/modern-go/reflect2"; fetch = { type = "git"; url = "https://github.com/modern-go/reflect2"; rev =  "4b7aa43c6742a2c18fdef89dd197aaae7dac7ccd"; sha256 = "1721y3yr3dpx5dx5ashf063qczk2awy5zjir1jvp1h5hn7qz4i49"; }; } { goPackagePath  = "github.com/petar/GoLLRB"; fetch = { type = "git"; url = "https://github.com/petar/GoLLRB"; rev =  "53be0d36a84c2a886ca057d34b6aa4468df9ccb4"; sha256 = "01xp3lcamqkvl91jg6ly202gdsgf64j39rkrcqxi6v4pbrcv7hz0"; }; } { goPackagePath  = "github.com/peterbourgon/diskv"; fetch = { type = "git"; url = "https://github.com/peterbourgon/diskv"; rev =  "5f041e8faa004a95c88a202771f4cc3e991971e6"; sha256 = "1mxpa5aad08x30qcbffzk80g9540wvbca4blc1r2qyzl65b8929b"; }; } { goPackagePath  = "github.com/pkg/errors"; fetch = { type = "git"; url = "https://github.com/pkg/errors"; rev =  "816c9085562cd7ee03e7f8188a1cfd942858cded"; sha256 = "1ws5crb7c70wdicavl6qr4g03nn6m92zd6wwp9n2ygz5c8rmxh8k"; }; } { goPackagePath  = "github.com/spf13/cobra"; fetch = { type = "git"; url = "https://github.com/spf13/cobra"; rev =  "a114f312e075f65bf30d6d9a1430113f857e543b"; sha256 = "10lmi5ni06yijxg02fcic5b7ycjkia12yma4a4lz8a56j30wykx1"; }; } { goPackagePath  = "github.com/spf13/pflag"; fetch = { type = "git"; url = "https://github.com/spf13/pflag"; rev =  "3ebe029320b2676d667ae88da602a5f854788a8a"; sha256 = "11yxs0wqy70wj106fkz8r923yg4ncnc2mbw33v48zmlg4a1rasgp"; }; } { goPackagePath  = "golang.org/x/crypto"; fetch = { type = "git"; url = "https://go.googlesource.com/crypto"; rev =  "49796115aa4b964c318aad4f3084fdb41e9aa067"; sha256 = "0pcq2drkzsw585xi6rda8imd7a139prrmvgmv8nz0zgzk6g4dy59"; }; } { goPackagePath  = "golang.org/x/net"; fetch = { type = "git"; url = "https://go.googlesource.com/net"; rev =  "1c05540f6879653db88113bc4a2b70aec4bd491f"; sha256 = "0h8yqb0vcqgllgydrf9d3rzp83w8wlr8f0nm6r1rwf2qg30pq1pd"; }; } { goPackagePath  = "golang.org/x/oauth2"; fetch = { type = "git"; url = "https://go.googlesource.com/oauth2"; rev =  "a6bd8cefa1811bd24b86f8902872e4e8225f74c4"; sha256 = "151in8qcf5y97ziavl6b03vgw4r87zqx5kg4vjhjszjbh60cfswp"; }; } { goPackagePath  = "golang.org/x/sys"; fetch = { type = "git"; url = "https://go.googlesource.com/sys"; rev =  "8e24a49d80f82323e1c4db1b5da3e0f31171a151"; sha256 = "0zsdnyb8dy98jw6f9yn6g5gdhaqwk39hqridr0mh4dhwvwvlj724"; }; } { goPackagePath  = "golang.org/x/text"; fetch = { type = "git"; url = "https://go.googlesource.com/text"; rev =  "f21a4dfb5e38f5895301dc265a8def02365cc3d0"; sha256 = "0r6x6zjzhr8ksqlpiwm5gdd7s209kwk5p4lw54xjvz10cs3qlq19"; }; } { goPackagePath  = "golang.org/x/time"; fetch = { type = "git"; url = "https://go.googlesource.com/time"; rev =  "f51c12702a4d776e4c1fa9b0fabab841babae631"; sha256 = "07wc6g2fvafkr6djsscm0jpbpl4135khhb6kpyx1953hi5d1jvyy"; }; } { goPackagePath  = "google.golang.org/appengine"; fetch = { type = "git"; url = "https://github.com/golang/appengine"; rev =  "ae0ab99deb4dc413a2b4bd6c8bdd0eb67f1e4d06"; sha256 = "1iabxnqgxvvn1239i6fvfl375vlbvhfrc03m1x2rvalmx4d6w9c7"; }; } { goPackagePath  = "gopkg.in/inf.v0"; fetch = { type = "git"; url = "https://github.com/go-inf/inf"; rev =  "3887ee99ecf07df5b447e9b00d9c0b2adaa9f3e4"; sha256 = "0rf3vwyb8aqnac9x9d6ax7z5526c45a16yjm2pvkijr6qgqz8b82"; }; } { goPackagePath  = "gopkg.in/yaml.v2"; fetch = { type = "git"; url = "https://github.com/go-yaml/yaml"; rev =  "5420a8b6744d3b0345ab293f6fcba19c978f1183"; sha256 = "0dwjrs2lp2gdlscs7bsrmyc5yf6mm4fvgw71bzr9mv2qrd2q73s1"; }; } { goPackagePath  = "k8s.io/api"; fetch = { type = "git"; url = "https://github.com/kubernetes/api"; rev =  "8be2a0b24ed0dac9cfc1ac2d987ea16cfcdbecb6"; sha256 = "1dpmd59jlkxgrp5aaf8420344c6nq4kjlc1avgcp7690yrzc50v6"; }; } { goPackagePath  = "k8s.io/apimachinery"; fetch = { type = "git"; url = "https://github.com/kubernetes/apimachinery"; rev =  "594fc14b6f143d963ea2c8132e09e73fe244b6c9"; sha256 = "0xykhpmjgagyb0ac4y0ps4v1s9bd2b1sc0simh48c41a9fk3yvr7"; }; } { goPackagePath  = "k8s.io/client-go"; fetch = { type = "git"; url = "https://github.com/kubernetes/client-go"; rev =  "739dd8f9d4801eb23e2bc43423c0b4acaaded29a"; sha256 = "15psjmb14rz4kwysim9vfbbylx0khkw29b195rziv1vk202lh28k"; }; } ] </del>  No newline at end of file


Question:
Describe the bug spacefm segfaults on start with the following output: invoke spacefm on the command line Expected behavior an up and running GUI program Screenshots see error message above Additional context I noticed that there is no It makes no difference whether spacefm is installed via nix-env or Notify maintainers Metadata** $ nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(root): channels(oo): nixpkgs:
I bisected this crash down to Perhaps the package needs to be updated to support the newer version of gtk3?
Hi. I cannot reproduce the crash with (current master). How about you?
Yep, that same binary segfaults for me. I'm on
still crashing with the same error message. Then out of curiosity I ran . The backtrace of the main thread has: 0x0000000000000000 in ?? () 0x00007fa6931c3ceb in ghashtablelookup () from /nix/store/hnk0s558k2h4v8abjzagagflvw1l0cb2-glib-2.66.4/lib/libglib- 0x00007fa69375c50c in gdkx11windowlookupfordisplay () from /nix/store/8pidhwid3ww58wlq705irf48c01dr0hv-gtk+3-3.24.24/lib/libgdk-3.so.0 0x0000000000499915 in getdesktopindex (win=win at main-window.c:4179 0x000000000049bfd1 in fmmainwindowgetoncurrentdesktop () at main-window.c:4225 0x0000000000496343 in handleparsedcommandlineargs () at main.c:1143 0x0000000000421808 in main (argc=<optimized out, argv=<optimized out) at main.c:1526 and now I am wondering about as I am running Wayland and sway. I don't know if it's relevant though.
Does it help if you run spacefm with the environment variable set? BTW, I am using X11.
Seems this a known bug:
GDKBACKEND=wayland does not help. Found an even older bug report from 2015: Question: this is an upstream known bug. Should I close this issue? (I don't know what the protocol is in this case)
I am not sure. Maybe we can at least improve something here? Change the description to call out that this does not work with wayland for example? Patch it that it fails gracefully with an explanatory message when not run under X11? Then, it seems the project is also not really maintained anymore. Maybe it's time to let it go?
Another idea: a wayland display driver (is this the right wording?) should fall back to x11 support via xwayland if an application cannot run under wayland natively. SpaceFM is a x11 only application, could you try to use and see if it makes a difference?
it actually runs with GDK_BACKEND=x11! Thanks for the suggestion.
I have created a PR to make x11 the only backend that is used.

sha256 = "089r6i40lxcwzp60553b18f130asspnzqldlpii53smz52kvpirx"; }; <del> patches = [ ./glibc-fix.patch ]; </del> <ins> patches = [ # fix compilation error due to missing include ./glibc-fix.patch # restrict GDK backends to only X11 ./x11-only.patch ]; </ins> configureFlags = [ "--with-bash-path=${pkgs.bash}/bin/bash"


Question:
Describe the bug spacefm segfaults on start with the following output: invoke spacefm on the command line Expected behavior an up and running GUI program Screenshots see error message above Additional context I noticed that there is no It makes no difference whether spacefm is installed via nix-env or Notify maintainers Metadata** $ nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(root): channels(oo): nixpkgs:
I bisected this crash down to Perhaps the package needs to be updated to support the newer version of gtk3?
Hi. I cannot reproduce the crash with (current master). How about you?
Yep, that same binary segfaults for me. I'm on
still crashing with the same error message. Then out of curiosity I ran . The backtrace of the main thread has: 0x0000000000000000 in ?? () 0x00007fa6931c3ceb in ghashtablelookup () from /nix/store/hnk0s558k2h4v8abjzagagflvw1l0cb2-glib-2.66.4/lib/libglib- 0x00007fa69375c50c in gdkx11windowlookupfordisplay () from /nix/store/8pidhwid3ww58wlq705irf48c01dr0hv-gtk+3-3.24.24/lib/libgdk-3.so.0 0x0000000000499915 in getdesktopindex (win=win at main-window.c:4179 0x000000000049bfd1 in fmmainwindowgetoncurrentdesktop () at main-window.c:4225 0x0000000000496343 in handleparsedcommandlineargs () at main.c:1143 0x0000000000421808 in main (argc=<optimized out, argv=<optimized out) at main.c:1526 and now I am wondering about as I am running Wayland and sway. I don't know if it's relevant though.
Does it help if you run spacefm with the environment variable set? BTW, I am using X11.
Seems this a known bug:
GDKBACKEND=wayland does not help. Found an even older bug report from 2015: Question: this is an upstream known bug. Should I close this issue? (I don't know what the protocol is in this case)
I am not sure. Maybe we can at least improve something here? Change the description to call out that this does not work with wayland for example? Patch it that it fails gracefully with an explanatory message when not run under X11? Then, it seems the project is also not really maintained anymore. Maybe it's time to let it go?
Another idea: a wayland display driver (is this the right wording?) should fall back to x11 support via xwayland if an application cannot run under wayland natively. SpaceFM is a x11 only application, could you try to use and see if it makes a difference?
it actually runs with GDK_BACKEND=x11! Thanks for the suggestion.
I have created a PR to make x11 the only backend that is used.

<ins> --- a/src/main.c	2021-02-09 13:54:32.847364236 +0100 +++ b/src/main.c	2021-02-09 10:41:51.541203271 +0100 @@ -1350,6 +1351,7 @@ vfs_file_monitor_clean(); return 1; } +            gdk_set_allowed_backends("x11"); gtk_init (&argc, &argv); int ret = custom_dialog_init( argc, argv ); if ( ret != 0 ) </ins>


Question:
Describe the bug (and, therefore, pretty much any package) fails to build on armv6l. To Reproduce Steps to reproduce the behavior: an armv6l machine. (I actually used an aarch64 Raspberry Pi 4B.) Additional context The segfault comes from , which is invoked by the Linux kernel build system. Here's a minimal C program that segfaults, when compiled with the from : A git bisect reveals that the faulty commit is (). Notify maintainers maintainer of binutils (since that's what seems to be the culprit here) author of Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(gaelan): channels(root): nixpkgs: Maintainer information:
I guess that this patch should only be enabled on armv7l then. Truthfully that PR was just changes proposed/written by others and someone else is probably more qualified wrt binutils to say what the correct thing to do would be.
I don't think it's an armv6l vs. armv7l thing: fails in the same way. There's a possibility that the issue is that I'm trying to build on a Pi 4, which is actually a 64-bit machine, with a 64-bit kernel. To test this, I copied the linux-headers closure, and all of its deps, to a Pi 0 W (which is actually armv6l), and got the same bug. It is still possible that the issue arises due to the Pi 4 miscompiling one of the dependences. I'm doing a full build on the Pi 0 to rule this out, but of course that could take a while.
Alright, also fails when building from scratch on a Pi 0. At this point, I'm pretty sure this patch just breaks building anything natively on aarch32.
Thanks for the testing I'm not sure what's more important, cross compiling to arm32 or native compiling! Hopefully can shed some light here.
What a mess! I guess the patch fixes some relocations breaks others. If we could make minimal programs for both that would be nice, but that's a lot of work.
Ah I see already minimized in , and we can cross-reference Jessica's patch on this issue too. So maybe once we minimize this issue we'll have enough combinations to try that it shouldn't be so bad.
I have this problem on armv7l as well, on the novena board. 5.9.8 headers required for building nix fail.
I'm running into the exact same issue using arm emulation via on my x64 machine.
IIRC GHC was the only package affected by the bug in my NixOS closure when I had it running on an armv7 machine back in 2019 and it was also happening on native builds; had nothing to do with musl or cross. Couldn't we just make a special binutils with the patch for GHC and the (at worst) handful of other programs which need it?
Hello everyone, I'm trying to make use of the recent changes. Here what I've done: I'm using the nix installer from . I guess this should actually not be needed any more as we now have for this merged . Using my Pi4 with 32bit kernel: pi $ uname -a Linux raspberrypi 5.10.17-v7l+ SMP Fri Apr 30 13:20:47 BST 2021 armv7l GNU/Linux on the unstable channel (should not be relevant) and on current running: now passes. W-h-o-o . However, compiling our friendly greeting: results in the following segfault: Seems like this PR has not been all to fix the broken target. Anyone aware of the issue here and how to continue? Happy to update the official Wiki as soon as I've things working ... also including the hydra tarball. Thanks!
try cherry-picking commit from
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Thanks . That definitely helped but failing at stage4 now: Hmm, looks like the OS killed it? - maybe OOM? I guess there is a way to reduce memory load by reducing the number of parallel jobs? Do we know the minimal config right now?
I had no issues building the entire system (with a few tweaks) on armv7l virtual machine with 4 cores and 4G of RAM. You can try building with . Do you use NixOS? If not, is nix installed in multi-user mode?
Yes, OOM often produces exactly this "killed" log line.
Also make sure you have zram swap (perhaps even with zstd) if you're running into OOM issues. It's free additional RAM space.
Hitting the exact same bug when cross-compiling to armv7l now, in packages that have PIC disabled (zfs)

# indeed GHC will refuse to compile with a binutils suffering from it. See # this comment for more information: # https://gitlab.haskell.org/ghc/ghc/issues/4210#note_78333 <del> lib.optional stdenv.targetPlatform.isAarch32 ./R_ARM_COPY.patch; </del> <ins> lib.optional (stdenv.targetPlatform.isAarch32 && stdenv.hostPlatform.system != stdenv.targetPlatform.system) ./R_ARM_COPY.patch; </ins> outputs = [ "out" "info" "man" ];


Question: Describe the bug There may be something flaky about the python3{789} build. It's been going on and off on hydra. I can't reliably reproduce the failures seen on hydra locally when building from the exact same commits that failed on hydra, but I have observed the same failure at least once on my machine. ! Expected behavior dask should build cleanly. Notify maintainers Metadata

"test_count_nonzero_str" "rolling_methods"  # floating percision error ~0.1*10^8 small "num_workers_config" # flaky <ins> "test_2args_with_array[pandas1-darray1-ldexp]"  # flaky </ins> ]; meta = {


Question:
Describe the bug Just lost on two different NixOS machine my Signal Desktop history because of this faulty update... I don't know, probably doesn't make sense for people to downgrade who are already upgraded but for others it dataloss To Reproduce Steps to reproduce the behavior: Signal Desktop Signal Desktop you to delete db, if you interact in a wrong way it will delete your data Notify maintainers ( and
Sorry to hear that. I recently lost my history too... It's really frustrating! Yeah, unfortunately I don't think there's anything we can do about it (as downstream package maintainers). AFAIK the source of the bug is still unknown, it doesn't seem to affect all users, and all releases have a limited lifetime ("expire" 90 days after the release, see my comment in ). Thanks for saying that! This really bothered me too... I just didn't say anything because I was too angry to keep it nice enough. (I raged a bit here but after I realized that one cannot even import old backups I had to take a break.)
I just got hit by a similar issue by moving from Archlinux (encrypted database) to NixOS (non encrypted database). After many things, the easiest fix to ensure proper functionalities IMHO is installing: This will disable tracker3 and prevent SQLite to be loaded in the process which will replace SQLCipher and cause the SQLite3 API to be the original one (i.e. non-encrypted) and cause many issues down the road I guess. That might not fix everything though :upsidedownface: Opened a PR:
FYI, in case anyone has feedback/suggestions: We might merge soon and it should cause another "Database startup error: Error: SQLITE_NOTADB: file is not a database" error (which is really unfortunate but not easily avoidable).
Heads-up: I've just merged to hopefully resolve this once and for all and the Python wrapper script should take care of the database re-encryption when launching Signal-Desktop as usual but the user experience isn't that great and you probably want to backup first in case the script fails unexpectedly.
Thank you, I just upgraded Signal on my computer and the re-encryption did work as intended

# - https://github.com/NixOS/nixpkgs/issues/108772 # - https://github.com/NixOS/nixpkgs/pull/117555 print(machine.succeed("su - alice -c 'file ~/.config/Signal/sql/db.sqlite'")) <del> # TODO: The DB should be encrypted and the following should be machine.fail # instead of machine.succeed but the DB is currently unencrypted and we # want to notice if this isn't the case anymore as the transition to a # encrypted DB can cause data loss!: </del> machine.succeed( <del> "su - alice -c 'file ~/.config/Signal/sql/db.sqlite' | grep -i sqlite" </del> <ins> "su - alice -c 'file ~/.config/Signal/sql/db.sqlite' | grep 'db.sqlite: data'" ) machine.fail( "su - alice -c 'file ~/.config/Signal/sql/db.sqlite' | grep -e SQLite -e database" </ins> ) ''; })


Question:
Describe the bug Just lost on two different NixOS machine my Signal Desktop history because of this faulty update... I don't know, probably doesn't make sense for people to downgrade who are already upgraded but for others it dataloss To Reproduce Steps to reproduce the behavior: Signal Desktop Signal Desktop you to delete db, if you interact in a wrong way it will delete your data Notify maintainers ( and
Sorry to hear that. I recently lost my history too... It's really frustrating! Yeah, unfortunately I don't think there's anything we can do about it (as downstream package maintainers). AFAIK the source of the bug is still unknown, it doesn't seem to affect all users, and all releases have a limited lifetime ("expire" 90 days after the release, see my comment in ). Thanks for saying that! This really bothered me too... I just didn't say anything because I was too angry to keep it nice enough. (I raged a bit here but after I realized that one cannot even import old backups I had to take a break.)
I just got hit by a similar issue by moving from Archlinux (encrypted database) to NixOS (non encrypted database). After many things, the easiest fix to ensure proper functionalities IMHO is installing: This will disable tracker3 and prevent SQLite to be loaded in the process which will replace SQLCipher and cause the SQLite3 API to be the original one (i.e. non-encrypted) and cause many issues down the road I guess. That might not fix everything though :upsidedownface: Opened a PR:
FYI, in case anyone has feedback/suggestions: We might merge soon and it should cause another "Database startup error: Error: SQLITE_NOTADB: file is not a database" error (which is really unfortunate but not easily avoidable).
Heads-up: I've just merged to hopefully resolve this once and for all and the Python wrapper script should take care of the database re-encryption when launching Signal-Desktop as usual but the user experience isn't that great and you probably want to backup first in case the script fails unexpectedly.
Thank you, I just upgraded Signal on my computer and the re-encryption did work as intended

<ins> #!@PYTHON@ import json import os import re import shlex import sqlite3 import subprocess import sys DB_PATH = os.path.join(os.environ['HOME'], '.config/Signal/sql/db.sqlite') DB_COPY = os.path.join(os.environ['HOME'], '.config/Signal/sql/db.tmp') CONFIG_PATH = os.path.join(os.environ['HOME'], '.config/Signal/config.json') def zenity_askyesno(title, text): args = [ '@ZENITY@', '--question', '--title', shlex.quote(title), '--text', shlex.quote(text) ] return subprocess.run(args).returncode == 0 def start_signal(): os.execvp('@SIGNAL-DESKTOP@', ['@SIGNAL-DESKTOP@'] + sys.argv[1:]) def copy_pragma(name): result = subprocess.run([ '@SQLCIPHER@', DB_PATH, f"PRAGMA {name};" ], check=True, capture_output=True).stdout result = re.search(r'[0-9]+', result.decode()).group(0) subprocess.run([ '@SQLCIPHER@', DB_COPY, f"PRAGMA key = "x'{key}'"; PRAGMA {name} = {result};" ], check=True, capture_output=True) try: # Test if DB is encrypted: con = sqlite3.connect(f'file:{DB_PATH}?mode=ro', uri=True) cursor = con.cursor() cursor.execute("SELECT name FROM sqlite_master WHERE type='table';") con.close() except: # DB is encrypted, everything ok: start_signal() # DB is unencrypted! answer = zenity_askyesno( "Error: Signal-Desktop database is not encrypted", "Should we try to fix this automatically?" + "You likely want to backup ~/.config/Signal/ first." ) if not answer: answer = zenity_askyesno( "Launch Signal-Desktop", "DB is unencrypted, should we still launch Signal-Desktop?" + "Warning: This could result in data loss!" ) if not answer: print('Aborted') sys.exit(0) start_signal() # Re-encrypt the DB: with open(CONFIG_PATH) as json_file: key = json.load(json_file)['key'] result = subprocess.run([ '@SQLCIPHER@', DB_PATH, f" ATTACH DATABASE '{DB_COPY}' AS signal_db KEY "x'{key}'";" + " SELECT sqlcipher_export('signal_db');" + " DETACH DATABASE signal_db;" ]).returncode if result != 0: print('DB encryption failed') sys.exit(1) # Need to copy user_version and schema_version manually: copy_pragma('user_version') copy_pragma('schema_version') os.rename(DB_COPY, DB_PATH) start_signal() </ins>


Question:
Describe the bug Just lost on two different NixOS machine my Signal Desktop history because of this faulty update... I don't know, probably doesn't make sense for people to downgrade who are already upgraded but for others it dataloss To Reproduce Steps to reproduce the behavior: Signal Desktop Signal Desktop you to delete db, if you interact in a wrong way it will delete your data Notify maintainers ( and
Sorry to hear that. I recently lost my history too... It's really frustrating! Yeah, unfortunately I don't think there's anything we can do about it (as downstream package maintainers). AFAIK the source of the bug is still unknown, it doesn't seem to affect all users, and all releases have a limited lifetime ("expire" 90 days after the release, see my comment in ). Thanks for saying that! This really bothered me too... I just didn't say anything because I was too angry to keep it nice enough. (I raged a bit here but after I realized that one cannot even import old backups I had to take a break.)
I just got hit by a similar issue by moving from Archlinux (encrypted database) to NixOS (non encrypted database). After many things, the easiest fix to ensure proper functionalities IMHO is installing: This will disable tracker3 and prevent SQLite to be loaded in the process which will replace SQLCipher and cause the SQLite3 API to be the original one (i.e. non-encrypted) and cause many issues down the road I guess. That might not fix everything though :upsidedownface: Opened a PR:
FYI, in case anyone has feedback/suggestions: We might merge soon and it should cause another "Database startup error: Error: SQLITE_NOTADB: file is not a database" error (which is really unfortunate but not easily avoidable).
Heads-up: I've just merged to hopefully resolve this once and for all and the Python wrapper script should take care of the database re-encryption when launching Signal-Desktop as usual but the user experience isn't that great and you probably want to backup first in case the script fails unexpectedly.
Thank you, I just upgraded Signal on my computer and the re-encryption did work as intended

, hunspellDicts, spellcheckerLanguage ? null # E.g. "de_DE" # For a full list of available languages: # $ cat pkgs/development/libraries/hunspell/dictionaries.nix | grep "dictFileName =" | awk '{ print $3 }' <ins> , python3 , gnome , sqlcipher </ins> }: let


Question:
Describe the bug Just lost on two different NixOS machine my Signal Desktop history because of this faulty update... I don't know, probably doesn't make sense for people to downgrade who are already upgraded but for others it dataloss To Reproduce Steps to reproduce the behavior: Signal Desktop Signal Desktop you to delete db, if you interact in a wrong way it will delete your data Notify maintainers ( and
Sorry to hear that. I recently lost my history too... It's really frustrating! Yeah, unfortunately I don't think there's anything we can do about it (as downstream package maintainers). AFAIK the source of the bug is still unknown, it doesn't seem to affect all users, and all releases have a limited lifetime ("expire" 90 days after the release, see my comment in ). Thanks for saying that! This really bothered me too... I just didn't say anything because I was too angry to keep it nice enough. (I raged a bit here but after I realized that one cannot even import old backups I had to take a break.)
I just got hit by a similar issue by moving from Archlinux (encrypted database) to NixOS (non encrypted database). After many things, the easiest fix to ensure proper functionalities IMHO is installing: This will disable tracker3 and prevent SQLite to be loaded in the process which will replace SQLCipher and cause the SQLite3 API to be the original one (i.e. non-encrypted) and cause many issues down the road I guess. That might not fix everything though :upsidedownface: Opened a PR:
FYI, in case anyone has feedback/suggestions: We might merge soon and it should cause another "Database startup error: Error: SQLITE_NOTADB: file is not a database" error (which is really unfortunate but not easily avoidable).
Heads-up: I've just merged to hopefully resolve this once and for all and the Python wrapper script should take care of the database re-encryption when launching Signal-Desktop as usual but the user experience isn't that great and you probably want to backup first in case the script fails unexpectedly.
Thank you, I just upgraded Signal on my computer and the re-encryption did work as intended

# Symlink to bin mkdir -p $out/bin <del> ln -s $out/lib/Signal/signal-desktop $out/bin/signal-desktop </del> <ins> ln -s $out/lib/Signal/signal-desktop $out/bin/signal-desktop-unwrapped </ins> runHook postInstall ''; <ins> # Required for $SQLCIPHER_LIB which contains "/build/" inside the path: noAuditTmpdir = true; </ins> preFixup = '' <ins> export SQLCIPHER_LIB="$out/lib/Signal/resources/app.asar.unpacked/node_modules/better-sqlite3/build/Release/better_sqlite3.node" test -x "$SQLCIPHER_LIB" # To ensure the location hasn't changed </ins> gappsWrapperArgs+=( --prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath [ stdenv.cc.cc ] }" <ins> --prefix LD_PRELOAD : "$SQLCIPHER_LIB" </ins> ${customLanguageWrapperArgs} )


Question:
Describe the bug Just lost on two different NixOS machine my Signal Desktop history because of this faulty update... I don't know, probably doesn't make sense for people to downgrade who are already upgraded but for others it dataloss To Reproduce Steps to reproduce the behavior: Signal Desktop Signal Desktop you to delete db, if you interact in a wrong way it will delete your data Notify maintainers ( and
Sorry to hear that. I recently lost my history too... It's really frustrating! Yeah, unfortunately I don't think there's anything we can do about it (as downstream package maintainers). AFAIK the source of the bug is still unknown, it doesn't seem to affect all users, and all releases have a limited lifetime ("expire" 90 days after the release, see my comment in ). Thanks for saying that! This really bothered me too... I just didn't say anything because I was too angry to keep it nice enough. (I raged a bit here but after I realized that one cannot even import old backups I had to take a break.)
I just got hit by a similar issue by moving from Archlinux (encrypted database) to NixOS (non encrypted database). After many things, the easiest fix to ensure proper functionalities IMHO is installing: This will disable tracker3 and prevent SQLite to be loaded in the process which will replace SQLCipher and cause the SQLite3 API to be the original one (i.e. non-encrypted) and cause many issues down the road I guess. That might not fix everything though :upsidedownface: Opened a PR:
FYI, in case anyone has feedback/suggestions: We might merge soon and it should cause another "Database startup error: Error: SQLITE_NOTADB: file is not a database" error (which is really unfortunate but not easily avoidable).
Heads-up: I've just merged to hopefully resolve this once and for all and the Python wrapper script should take care of the database re-encryption when launching Signal-Desktop as usual but the user experience isn't that great and you probably want to backup first in case the script fails unexpectedly.
Thank you, I just upgraded Signal on my computer and the re-encryption did work as intended

patchelf --add-needed ${libpulseaudio}/lib/libpulse.so $out/lib/Signal/resources/app.asar.unpacked/node_modules/ringrtc/build/linux/libringrtc.node ''; <ins> postFixup = '' # This hack is temporarily required to avoid data-loss for users: cp ${./db-reencryption-wrapper.py} $out/bin/signal-desktop substituteInPlace $out/bin/signal-desktop  --replace '@PYTHON@' '${python3}/bin/python3'  --replace '@ZENITY@' '${gnome.zenity}/bin/zenity'  --replace '@SQLCIPHER@' '${sqlcipher}/bin/sqlcipher'  --replace '@SIGNAL-DESKTOP@' "$out/bin/signal-desktop-unwrapped" ''; </ins> # Tests if the application launches and waits for "Link your phone to Signal Desktop": passthru.tests.application-launch = nixosTests.signal-desktop;


Question:
Carry over discussion from IRC #nixos-dev and . Inspired by the doc change in recommending top-level usage of over , we want to reduce confusion for newcomers and unnecessary complexity by making the canonical way to access the Nix library. We may still want to keep to not break external code, and place a or similar at its definition site. There are over files where occurs at least once. Beyond splitting this change across multiple PRs, in what ways can the change be automated? Pinging
In the short term, we could add this check in ofbrorg and , and update any examples in the documentation to reduce new usage of .
Don't forget things like and .
Ah. So 45K occurrences across 11.8K files.
toplevel is done
the xorg dep generator also doesn’t put it in its output anymore
trewide rewrite in
doc changes in
Graph of occurrences over time:
Nice! What scripts did you use to generate it?
There's a source code link now :)
Found another large source of s. Fixing cabal2nix should remove around 24k occurrences in .
Status report
Just found out that counts stuff like as well, so
Is it ok to rewrite to ?
That's the lib output of , so no.
an easy way to find out is to evaluate both in
Subfolders of with <10 changes needed in PR
Around + replacements out of 30k+ are concentrated in - should be trivial to regenerate the file with the new desired contents.
I'm working on it but it's a bit more complicated than I anticipated.
What problems are you running into?
Part of code generation of cabal2nix is in an external dependency, so I had to open two PRs. The dependency is itself on Hackage, so we may have to wait until the change propagates to Stackage LTS and then Nixpkgs, unless peti will use an override or something: I'm not familiar with the cabal2nix workflow.
I think the haskell-updates are mostly done from a local checkout of cabal2nix, so it depends mostly on what version peter is using. You can also probably just ask him, he is generally available for such things on his .
could you help here?
The Haskell infrastructure has switched to the new style with commit . It will land in this Friday. I have also updated the generator code and released new versions to Hackage, so I guess the Haskell infrastructure can be considered done.
Thank you
More accurate regex: (the one above captures stuff like
When is merged, this will be the result Three Nix files remain that use directly.
The last usages of it can be found by commenting out where it is inherited in .
I just got this warning while doing a , but it doesn't give me any info as to which derivations are at fault. Is there any way we could improve the message to identify culprits?
With , you should get a hard error which will allow you to use . Or you can update Nixpkgs, since it has been removed in

<itemizedlist> <listitem> <para> <ins> <literal>stdenv.lib</literal> has been deprecated and will break eval in 21.11.  Please use <literal>pkgs.lib</literal> instead. See <link xlink:href="https://github.com/NixOS/nixpkgs/issues/108938">#108938</link> for details. </para> </listitem> <listitem> <para> </ins> The Mailman NixOS module (<literal>services.mailman</literal>) has a new option <xref linkend="opt-services.mailman.enablePostfix" />, defaulting to true, that controls integration with Postfix.


Question:
Carry over discussion from IRC #nixos-dev and . Inspired by the doc change in recommending top-level usage of over , we want to reduce confusion for newcomers and unnecessary complexity by making the canonical way to access the Nix library. We may still want to keep to not break external code, and place a or similar at its definition site. There are over files where occurs at least once. Beyond splitting this change across multiple PRs, in what ways can the change be automated? Pinging
In the short term, we could add this check in ofbrorg and , and update any examples in the documentation to reduce new usage of .
Don't forget things like and .
Ah. So 45K occurrences across 11.8K files.
toplevel is done
the xorg dep generator also doesn’t put it in its output anymore
trewide rewrite in
doc changes in
Graph of occurrences over time:
Nice! What scripts did you use to generate it?
There's a source code link now :)
Found another large source of s. Fixing cabal2nix should remove around 24k occurrences in .
Status report
Just found out that counts stuff like as well, so
Is it ok to rewrite to ?
That's the lib output of , so no.
an easy way to find out is to evaluate both in
Subfolders of with <10 changes needed in PR
Around + replacements out of 30k+ are concentrated in - should be trivial to regenerate the file with the new desired contents.
I'm working on it but it's a bit more complicated than I anticipated.
What problems are you running into?
Part of code generation of cabal2nix is in an external dependency, so I had to open two PRs. The dependency is itself on Hackage, so we may have to wait until the change propagates to Stackage LTS and then Nixpkgs, unless peti will use an override or something: I'm not familiar with the cabal2nix workflow.
I think the haskell-updates are mostly done from a local checkout of cabal2nix, so it depends mostly on what version peter is using. You can also probably just ask him, he is generally available for such things on his .
could you help here?
The Haskell infrastructure has switched to the new style with commit . It will land in this Friday. I have also updated the generator code and released new versions to Hackage, so I guess the Haskell infrastructure can be considered done.
Thank you
More accurate regex: (the one above captures stuff like
When is merged, this will be the result Three Nix files remain that use directly.
The last usages of it can be found by commenting out where it is inherited in .
I just got this warning while doing a , but it doesn't give me any info as to which derivations are at fault. Is there any way we could improve the message to identify culprits?
With , you should get a hard error which will allow you to use . Or you can update Nixpkgs, since it has been removed in

}; patchPhase = "patchShebangs ."; <del> preBuild = stdenv.lib.optionalString (stdenv.hostPlatform != stdenv.buildPlatform) '' </del> <ins> preBuild = lib.optionalString (stdenv.hostPlatform != stdenv.buildPlatform) '' </ins> make CC=${buildPackages.stdenv.cc}/bin/cc find_sizes mv find_sizes find_sizes_build make clean substituteInPlace Makefile --replace "./find_sizes" "./find_sizes_build" <del> substituteInPlace Makefile --replace "ar cr" "${stdenv.lib.getBin stdenv.cc.bintools.bintools}/bin/${stdenv.cc.targetPrefix}ar cr" substituteInPlace Makefile --replace "ranlib" "${stdenv.lib.getBin stdenv.cc.bintools.bintools}/bin/${stdenv.cc.targetPrefix}ranlib" substituteInPlace Makefile --replace "STRIP=strip" "STRIP=${stdenv.lib.getBin stdenv.cc.bintools.bintools}/bin/${stdenv.cc.targetPrefix}strip" </del> <ins> substituteInPlace Makefile --replace "ar cr" "${lib.getBin stdenv.cc.bintools.bintools}/bin/${stdenv.cc.targetPrefix}ar cr" substituteInPlace Makefile --replace "ranlib" "${lib.getBin stdenv.cc.bintools.bintools}/bin/${stdenv.cc.targetPrefix}ranlib" substituteInPlace Makefile --replace "STRIP=strip" "STRIP=${lib.getBin stdenv.cc.bintools.bintools}/bin/${stdenv.cc.targetPrefix}strip" </ins> ''; nativeBuildInputs = [ perl zlib ]; #  buildInputs = [ zlib ];


Question:
Carry over discussion from IRC #nixos-dev and . Inspired by the doc change in recommending top-level usage of over , we want to reduce confusion for newcomers and unnecessary complexity by making the canonical way to access the Nix library. We may still want to keep to not break external code, and place a or similar at its definition site. There are over files where occurs at least once. Beyond splitting this change across multiple PRs, in what ways can the change be automated? Pinging
In the short term, we could add this check in ofbrorg and , and update any examples in the documentation to reduce new usage of .
Don't forget things like and .
Ah. So 45K occurrences across 11.8K files.
toplevel is done
the xorg dep generator also doesn’t put it in its output anymore
trewide rewrite in
doc changes in
Graph of occurrences over time:
Nice! What scripts did you use to generate it?
There's a source code link now :)
Found another large source of s. Fixing cabal2nix should remove around 24k occurrences in .
Status report
Just found out that counts stuff like as well, so
Is it ok to rewrite to ?
That's the lib output of , so no.
an easy way to find out is to evaluate both in
Subfolders of with <10 changes needed in PR
Around + replacements out of 30k+ are concentrated in - should be trivial to regenerate the file with the new desired contents.
I'm working on it but it's a bit more complicated than I anticipated.
What problems are you running into?
Part of code generation of cabal2nix is in an external dependency, so I had to open two PRs. The dependency is itself on Hackage, so we may have to wait until the change propagates to Stackage LTS and then Nixpkgs, unless peti will use an override or something: I'm not familiar with the cabal2nix workflow.
I think the haskell-updates are mostly done from a local checkout of cabal2nix, so it depends mostly on what version peter is using. You can also probably just ask him, he is generally available for such things on his .
could you help here?
The Haskell infrastructure has switched to the new style with commit . It will land in this Friday. I have also updated the generator code and released new versions to Hackage, so I guess the Haskell infrastructure can be considered done.
Thank you
More accurate regex: (the one above captures stuff like
When is merged, this will be the result Three Nix files remain that use directly.
The last usages of it can be found by commenting out where it is inherited in .
I just got this warning while doing a , but it doesn't give me any info as to which derivations are at fault. Is there any way we could improve the message to identify culprits?
With , you should get a hard error which will allow you to use . Or you can update Nixpkgs, since it has been removed in

<del> { stdenv </del> <ins> { lib , stdenv </ins> , rustPlatform , fetchFromGitHub , nix-update-script


Question:
Carry over discussion from IRC #nixos-dev and . Inspired by the doc change in recommending top-level usage of over , we want to reduce confusion for newcomers and unnecessary complexity by making the canonical way to access the Nix library. We may still want to keep to not break external code, and place a or similar at its definition site. There are over files where occurs at least once. Beyond splitting this change across multiple PRs, in what ways can the change be automated? Pinging
In the short term, we could add this check in ofbrorg and , and update any examples in the documentation to reduce new usage of .
Don't forget things like and .
Ah. So 45K occurrences across 11.8K files.
toplevel is done
the xorg dep generator also doesn’t put it in its output anymore
trewide rewrite in
doc changes in
Graph of occurrences over time:
Nice! What scripts did you use to generate it?
There's a source code link now :)
Found another large source of s. Fixing cabal2nix should remove around 24k occurrences in .
Status report
Just found out that counts stuff like as well, so
Is it ok to rewrite to ?
That's the lib output of , so no.
an easy way to find out is to evaluate both in
Subfolders of with <10 changes needed in PR
Around + replacements out of 30k+ are concentrated in - should be trivial to regenerate the file with the new desired contents.
I'm working on it but it's a bit more complicated than I anticipated.
What problems are you running into?
Part of code generation of cabal2nix is in an external dependency, so I had to open two PRs. The dependency is itself on Hackage, so we may have to wait until the change propagates to Stackage LTS and then Nixpkgs, unless peti will use an override or something: I'm not familiar with the cabal2nix workflow.
I think the haskell-updates are mostly done from a local checkout of cabal2nix, so it depends mostly on what version peter is using. You can also probably just ask him, he is generally available for such things on his .
could you help here?
The Haskell infrastructure has switched to the new style with commit . It will land in this Friday. I have also updated the generator code and released new versions to Hackage, so I guess the Haskell infrastructure can be considered done.
Thank you
More accurate regex: (the one above captures stuff like
When is merged, this will be the result Three Nix files remain that use directly.
The last usages of it can be found by commenting out where it is inherited in .
I just got this warning while doing a , but it doesn't give me any info as to which derivations are at fault. Is there any way we could improve the message to identify culprits?
With , you should get a hard error which will allow you to use . Or you can update Nixpkgs, since it has been removed in

nativeBuildInputs = [ makeWrapper ]; postInstall = '' <del> wrapProgram $out/bin/cargo-valgrind --prefix PATH : ${stdenv.lib.makeBinPath [ valgrind ]} </del> <ins> wrapProgram $out/bin/cargo-valgrind --prefix PATH : ${lib.makeBinPath [ valgrind ]} </ins> ''; <del> meta = with stdenv.lib; { </del> <ins> meta = with lib; { </ins> description = ''Cargo subcommand "valgrind": runs valgrind and collects its output in a helpful manner''; homepage = "https://github.com/jfrimmel/cargo-valgrind"; license = with licenses; [ asl20 /* or */ mit ];