Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: nixos.poppler <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 21.05.0 desired version: 21.06.01 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR. The current version of is causing evince to crash frequently:

meta = with lib; { homepage = "https://poppler.freedesktop.org/"; description = "A PDF rendering library"; longDescription = '' Poppler is a PDF rendering library based on the xpdf-3.0 code base. ''; <del> license = licenses.gpl2; </del> <ins> license = licenses.gpl2Plus; </ins> platforms = platforms.all; maintainers = with maintainers; [ ttuegel ]; };


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: nixos.poppler <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 21.05.0 desired version: 21.06.01 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR. The current version of is causing evince to crash frequently:

<del> { stdenv , lib </del> <ins> { lib , stdenv </ins> , fetchurl , fetchpatch <ins> , cairo </ins> , cmake <del> , ninja , pkg-config , libiconv , libintl , zlib </del> <ins> , pcre , boost , cups-filters </ins> , curl <del> , cairo , freetype </del> , fontconfig <ins> , freetype , inkscape </ins> , lcms <ins> , libiconv , libintl </ins> , libjpeg <ins> , ninja </ins> , openjpeg <ins> , pkg-config , scribusUnstable , texlive , zlib </ins> , withData ? true, poppler_data , qt5Support ? false, qtbase ? null , introspectionSupport ? false, gobject-introspection ? null , utils ? false, nss ? null , minimal ? false , suffix ? "glib" <del> , inkscape , cups-filters , texlive , scribusUnstable </del> }: let mkFlag = optset: flag: "-DENABLE_${flag}=${if optset then "on" else "off"}"; in stdenv.mkDerivation rec { <del> name = "poppler-${suffix}-${version}"; version = "21.05.0"; # beware: updates often break cups-filters build, check texlive and scribusUnstable too! </del> <ins> pname = "poppler-${suffix}"; version = "21.06.1"; # beware: updates often break cups-filters build, check texlive and scribusUnstable too! </ins> outputs = [ "out" "dev" ]; src = fetchurl { <del> url = "${meta.homepage}/poppler-${version}.tar.xz"; sha256 = "sha256-2v1Te2gPrRIVvED8U9HzjoRJ18GFvGDVqJ4dJskNvYw="; </del> <ins> url = "https://poppler.freedesktop.org/poppler-${version}.tar.xz"; sha256 = "sha256-hrCeWgLeQAgaORbvhxHFEo6vSx/FnV+H0Oxm8E9ZXbQ="; </ins> }; nativeBuildInputs = [


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: nixos.poppler <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 21.05.0 desired version: 21.06.01 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR. The current version of is causing evince to crash frequently:

]; buildInputs = [ <ins> boost pcre </ins> libiconv libintl ] ++ lib.optional withData [


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: nixos.poppler <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 21.05.0 desired version: 21.06.01 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR. The current version of is causing evince to crash frequently:

meta = with lib; { homepage = "https://poppler.freedesktop.org/"; description = "A PDF rendering library"; longDescription = '' <del> Poppler is a PDF rendering library based on the xpdf-3.0 code base. In addition it provides a number of tools that can be installed separately. </del> <ins> Poppler is a PDF rendering library based on the xpdf-3.0 code base. In addition it provides a number of tools that can be installed separately. </ins> ''; license = licenses.gpl2Plus; platforms = platforms.all; maintainers = with maintainers; [ ttuegel ] ++ teams.freedesktop.members;


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: nixos.poppler <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 21.05.0 desired version: 21.06.01 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR. The current version of is causing evince to crash frequently:

suffix = "min"; }; <del> poppler_utils = poppler.override { suffix = "utils"; utils = true; }; </del> <ins> poppler_utils = poppler.override { suffix = "utils"; utils = true; }; </ins> popt = callPackage ../development/libraries/popt { };


Question:
Currently, we first build a derivation containing the unpacked Chromium source code, which is then passed to the actual Chrome build. This is very inefficient: the unpacked source tree is 1.8 GB and ~85K files. Copying these between build machines can take a very long time: for instance, the is currently showing two builds (in the copying state) which have already taken 22 hours. So it would be better to do whatever does in the derivation.
didn't we do this because IO was too slow for unpacking in NixOS tests?
I don't think the tests need the source code.
Is there another way to avoid copying source derivations between machines? I think the source derivation is good to keep, I want to have QtWebEngine which uses chromium, would be nice to use chromium source and all patches that is used. Would this still be possible (in a easy way) if chromium-source is removed?
The derivation could create a (compressed) tarball. That would help a lot since then Hydra won't have to do a huge amount of random access I/O reading/writing lots of small files.
The reason I've done it that way was to separate bundled dependencies and the sandbox from the main source, so for example if we want to build just the sandbox, we don't need to extract the full Chromium source. But I'll look into it so we can find a better solution, right now it's not working as I had in mind back then, because the source is copied into the temporary build directory, but a better solution would be to not copy anything at all.
I don't think you can re-use for this, as Qt uses a rather heavily modified version of the source.
Great point. I will add too that even if it was vanilla, chrome source moves far too quickly to be a dependency of a qt component. QtWebEngine is; I suspect using their own fork of the blink fork of webcore (webkit.) (webengine) If we look at the chromium release schedule they are trying to hit a release almost every month. If someone is quick (Before 19th of this month) they could apply for a gsoc to possibly get this chromium work done (worth a try?)
With S3 and decentralized hydra, we should really combine the source back. Currently this is blocking a channel update:
Working on this right now.
I've also the relevant changes to .
There's reference to the old path of the file on line 33 of this file:

{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:
Currently, we first build a derivation containing the unpacked Chromium source code, which is then passed to the actual Chrome build. This is very inefficient: the unpacked source tree is 1.8 GB and ~85K files. Copying these between build machines can take a very long time: for instance, the is currently showing two builds (in the copying state) which have already taken 22 hours. So it would be better to do whatever does in the derivation.
didn't we do this because IO was too slow for unpacking in NixOS tests?
I don't think the tests need the source code.
Is there another way to avoid copying source derivations between machines? I think the source derivation is good to keep, I want to have QtWebEngine which uses chromium, would be nice to use chromium source and all patches that is used. Would this still be possible (in a easy way) if chromium-source is removed?
The derivation could create a (compressed) tarball. That would help a lot since then Hydra won't have to do a huge amount of random access I/O reading/writing lots of small files.
The reason I've done it that way was to separate bundled dependencies and the sandbox from the main source, so for example if we want to build just the sandbox, we don't need to extract the full Chromium source. But I'll look into it so we can find a better solution, right now it's not working as I had in mind back then, because the source is copied into the temporary build directory, but a better solution would be to not copy anything at all.
I don't think you can re-use for this, as Qt uses a rather heavily modified version of the source.
Great point. I will add too that even if it was vanilla, chrome source moves far too quickly to be a dependency of a qt component. QtWebEngine is; I suspect using their own fork of the blink fork of webcore (webkit.) (webengine) If we look at the chromium release schedule they are trying to hit a release almost every month. If someone is quick (Before 19th of this month) they could apply for a gsoc to possibly get this chromium work done (worth a try?)
With S3 and decentralized hydra, we should really combine the source back. Currently this is blocking a channel update:
Working on this right now.
I've also the relevant changes to .
There's reference to the old path of the file on line 33 of this file:

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


Question: Project description The driver supports Realtek 8852AE, which is a wifi card for some new laptops. Without the driver, the wireless interface would be missing for those computers. (My new Lenovo laptop uses this card and I cannot connect to WiFI currently... I'm not entirely sure how to package this) Metadata homepage URL: source URL: license: GPA 2.0 platforms: Linux

<ins> { stdenvNoCC, lib, linuxPackages }: stdenvNoCC.mkDerivation { pname = "rtw89-firmware"; inherit (linuxPackages.rtw89) version src; dontBuild = true; installPhase = '' runHook preInstall mkdir -p $out/lib/firmware/rtw89 cp *.bin $out/lib/firmware/rtw89 runHook postInstall ''; meta = with lib; { description = "Driver for Realtek 8852AE, an 802.11ax device"; homepage = "https://github.com/lwfinger/rtw89"; license = licenses.unfreeRedistributableFirmware; maintainers = with maintainers; [ tvorog ]; platforms = platforms.linux; }; } </ins>


Question: Project description The driver supports Realtek 8852AE, which is a wifi card for some new laptops. Without the driver, the wireless interface would be missing for those computers. (My new Lenovo laptop uses this card and I cannot connect to WiFI currently... I'm not entirely sure how to package this) Metadata homepage URL: source URL: license: GPA 2.0 platforms: Linux

<ins> { stdenv, lib, fetchFromGitHub, kernel }: let modDestDir = "$out/lib/modules/${kernel.modDirVersion}/kernel/drivers/net/wireless/realtek/rtw89"; in stdenv.mkDerivation { pname = "rtw89"; version = "unstable-2021-07-03"; src = fetchFromGitHub { owner = "lwfinger"; repo = "rtw89"; rev = "cebafc6dc839e66c725b92c0fabf131bc908f607"; sha256 = "1vw67a423gajpzd5d51bxnja1qpppx9x5ii2vcfkj6cbnqwr83af"; }; makeFlags = [ "KSRC=${kernel.dev}/lib/modules/${kernel.modDirVersion}/build" ]; enableParallelBuilding = true; installPhase = '' runHook preInstall mkdir -p ${modDestDir} find . -name '*.ko' -exec cp --parents {} ${modDestDir} ; find ${modDestDir} -name '*.ko' -exec xz -f {} ; runHook postInstall ''; meta = with lib; { description = " Driver for Realtek 8852AE, an 802.11ax device"; homepage = "https://github.com/lwfinger/rtw89"; license = with licenses; [ gpl2Only ]; maintainers = with maintainers; [ tvorog ]; platforms = platforms.linux; broken = kernel.kernelOlder "5.4"; priority = -1; }; } </ins>


Question: Project description The driver supports Realtek 8852AE, which is a wifi card for some new laptops. Without the driver, the wireless interface would be missing for those computers. (My new Lenovo laptop uses this card and I cannot connect to WiFI currently... I'm not entirely sure how to package this) Metadata homepage URL: source URL: license: GPA 2.0 platforms: Linux

rtw88 = callPackage ../os-specific/linux/rtw88 { }; rtlwifi_new = rtw88; <ins> rtw89 = callPackage ../os-specific/linux/rtw89 { }; </ins> openafs_1_8 = callPackage ../servers/openafs/1.8/module.nix { }; openafs_1_9 = callPackage ../servers/openafs/1.9/module.nix { }; # Current stable release; don't backport release updates!


Question: Project description The driver supports Realtek 8852AE, which is a wifi card for some new laptops. Without the driver, the wireless interface would be missing for those computers. (My new Lenovo laptop uses this card and I cannot connect to WiFI currently... I'm not entirely sure how to package this) Metadata homepage URL: source URL: license: GPA 2.0 platforms: Linux

rtw88-firmware = callPackage ../os-specific/linux/firmware/rtw88-firmware { }; <ins> rtw89-firmware = callPackage ../os-specific/linux/firmware/rtw89-firmware { }; </ins> s3ql = callPackage ../tools/backup/s3ql { }; sass = callPackage ../development/tools/sass { };


Question:
Describe the bug With the latest kernel and the latest non-beta nvidia driver, the drivers don't compile: To Reproduce Steps to reproduce the behavior: unstable the latest linux kernel nvidia as a drivers Expected behavior It should compile. Notify maintainers Latest person who touched it: Metadata
I can reproduce this issue, albeit I am using stable channel with the latest kernel.
tl;dr for everyone facing this: should serve as a temporary workaround
I think we should implement some kind of kernel version lock for the nvidia driver to prevent such occurrences in the future.

# Policy: use the highest stable version as the default (on our master). stable = if stdenv.hostPlatform.system == "x86_64-linux" then generic { <del> version = "460.73.01"; sha256_64bit = "120ymf59l6nipczszf82lrm2p4ihhqyv2pfwwfg9wy96vqcckc8i"; settingsSha256 = "08jh7g34p9yxv5fh1cw0r2pjx65ryiv3w2lk1qg0gxn2r7xypkx0"; persistencedSha256 = "040gx4wqp3hxcfb4aba4sl7b01ixr5slhzw0xldwcqlmhpwqphi5"; </del> <ins> version = "470.57.02"; sha256_64bit = "sha256-VdeuEEgn+qeel1Mh/itg+d1C+/9lZCBTRDwOVv20xH0="; settingsSha256 = "sha256-DJg5QbyuKJmPpLQVYgTLvucI1e9YgQOO16690VXIWvk="; persistencedSha256 = "sha256-Cqv6oUFnsSi3S1sjplJKeq9bI2pqgBXPPb11HOJSlDo="; </ins> } else legacy_390;


Question:
I get the following output from :
Thanks, So fast. :)
This one was rather easy :-)


Question:
I get the following output from :
Thanks, So fast. :)
This one was rather easy :-)


Question:
Describe the bug The cinnamon-menu-editor doesn't open the cinnamon-desktop-editor, if I want to change the 'Properties' of a menu Entry. To Reproduce https://user- Expected behavior https://user- Additional context Here is the cinnamon-desktop-editor source: Notify maintainers thanks for making cinnamon available in NixOS! :) Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(linux): nixpkgs: Maintainer information:
Open the menu editor through the terminal and edit the properties then send the output
I open cinnamon-menu-editor in Terminal, select an entry, click "Properties": This is in the launcher- :
I marked this as stale due to inactivity. →
This patch fixes the issue, if nobody wish to investigate on this issue I will go ahead and commit this change on next cinnamon update. Edit: Ah I probably don't need to set dontWrapPythonPrograms Edit 2: Non English user can still encounter some l10n issues like translated strings are not modified, we will track the issue in

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 The cinnamon-menu-editor doesn't open the cinnamon-desktop-editor, if I want to change the 'Properties' of a menu Entry. To Reproduce https://user- Expected behavior https://user- Additional context Here is the cinnamon-desktop-editor source: Notify maintainers thanks for making cinnamon available in NixOS! :) Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(linux): nixpkgs: Maintainer information:
Open the menu editor through the terminal and edit the properties then send the output
I open cinnamon-menu-editor in Terminal, select an entry, click "Properties": This is in the launcher- :
I marked this as stale due to inactivity. →
This patch fixes the issue, if nobody wish to investigate on this issue I will go ahead and commit this change on next cinnamon update. Edit: Ah I probably don't need to set dontWrapPythonPrograms Edit 2: Non English user can still encounter some l10n issues like translated strings are not modified, we will track the issue in

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: Describe the bug Neo4j does not start because it cannot locate a Java Runtime. To Reproduce On my system, I installed with: Then, running shows: "The operation couldn’t be completed. Unable to locate a Java Runtime." Expected behavior Neo4j should start. Additional context Note that shows Note the line that sets to . Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:

<del> { lib, stdenv, fetchurl, makeWrapper, jre8, which, gawk }: </del> <ins> { lib, stdenv, fetchurl, makeWrapper, jre, which, gawk }: </ins> with lib;


Question: Describe the bug Neo4j does not start because it cannot locate a Java Runtime. To Reproduce On my system, I installed with: Then, running shows: "The operation couldn’t be completed. Unable to locate a Java Runtime." Expected behavior Neo4j should start. Additional context Note that shows Note the line that sets to . Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:

}; nativeBuildInputs = [ makeWrapper ]; <del> buildInputs = [ jre8 which gawk ]; </del> installPhase = '' mkdir -p "$out/share/neo4j"


Question: Describe the bug Neo4j does not start because it cannot locate a Java Runtime. To Reproduce On my system, I installed with: Then, running shows: "The operation couldn’t be completed. Unable to locate a Java Runtime." Expected behavior Neo4j should start. Additional context Note that shows Note the line that sets to . Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:

do makeWrapper "$out/share/neo4j/bin/$NEO4J_SCRIPT"  "$out/bin/$NEO4J_SCRIPT"  <del> --prefix PATH : "${lib.makeBinPath [ jre8 which gawk ]}"  --set JAVA_HOME "$jre8" </del> <ins> --prefix PATH : "${lib.makeBinPath [ jre which gawk ]}"  --set JAVA_HOME "${jre}" </ins> done '';


Question: Describe the bug Neo4j does not start because it cannot locate a Java Runtime. To Reproduce On my system, I installed with: Then, running shows: "The operation couldn’t be completed. Unable to locate a Java Runtime." Expected behavior Neo4j should start. Additional context Note that shows Note the line that sets to . Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:

check_systemd = callPackage ../servers/monitoring/nagios/plugins/check_systemd.nix { }; <del> neo4j = callPackage ../servers/nosql/neo4j { }; </del> <ins> neo4j = callPackage ../servers/nosql/neo4j { jre = jre8_headless; }; </ins> neo4j-desktop = callPackage ../applications/misc/neo4j-desktop { };


Question:
Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: to chromium 91.0.4472.164 (current on unstable channel) chromium that some area where there should be text do not render, this also happens in the developer console or at chrome://gpu/ for example. Expected behavior No error in font rendering Screenshots ! or ! Additional informations Works on some pages, like or teams, when directly accessing a meeting. Same behavior observed by a colleague running qutebrowser: ! (this is ) ^. ; ; ;,- ,- ,-"""   ^^ ,-; ; ,- / ;; ,^ / ,^ ,-" - qutebrowser v2.3.0 Git commit: Backend: QtWebEngine 5.15.3, based on Chromium 87.0.4280.144 Qt: 5.15.2 CPython: 3.9.5 PyQt: 5.15.4 sip: 6.1.0.dev2104271705 colorama: no jinja2: 3.0.1 pygments: 2.9.0 yaml: 5.4.1 adblock: 0.5.0 PyQt5.QtWebEngineWidgets: yes PyQt5.QtWebEngine: 5.15.4 PyQt5.QtWebKitWidgets: no 2.8.335 (/nix/store/z5n6n43w80lh2p2pfp694q38chlrmnl0-pdfjs-) sqlite: 3.35.5 QtNetwork SSL: OpenSSL 1.1.1k 25 Mar 2021 Style: QFusionStyle Platform plugin: xcb OpenGL: Intel, 4.6 (Compatibility Profile) Mesa 21.1.5 Platform: Linux-5.10.48-x86_64-with-glibc2.33, 64bit Linux distribution: NixOS 21.11 (Porcupine) (nixos) Frozen: False Imported from /nix/store/42sm4xmn4z74m19q7n70b7bgikd9qcy9-qutebrowser-2.3.0/lib/python3.9/site-packages/qutebrowser Using Python from /nix/store/yqjhkdarf7p74wcha7aypzsb751n7wl2-python3-3.9.5/bin/python3.9 Qt library executable path: /nix/store/i1gvlgf0g8scyc9rqk9gcz0pvwnvy6sp-qtbase-5.15.2/libexec, data path: /nix/store/i1gvlgf0g8scyc9rqk9gcz0pvwnvy6sp-qtbase-5.15.2 yaml attribute: chromium module:
Rolling back to chromium v91.0.4472.114 fixes the problem:
I can confirm this issue. All browsers based on seem to be affected. Qutebrowser definitely is.
I can also confirm it (noticed it a few hours ago) but didn't have time to investigate so far. A good revision is and a bad revision so something between those two revisions must've caused this regression (it's unrelated to Chromium updates). I suspect either or maybe .
I'm personally experiencing this in both qutebrowser and Chromium (but Chromium works with on the command line). From what I can tell, this does seem to be caused by the glibc 2.33 update: Chromium bug tracker issue QtWebEngine bug tracker issue Fix in Chromium (this one got reverted) (in version 94, the current dev channel version) Fedora patches for Chromium and QtWebEngine Arch patches for Chromium and QtWebEngine
(qtwebengine maintainer): Could you look into the fix for QtWebEngine (see )? cc (qutebrowser maintainers) Regarding Chromium: should hopefully fix this regression:

url = "https://github.com/qt/qtwebengine/commit/199ea00a9eea13315a652c62778738629185b059.patch"; sha256 = "1b5k2g1v8913cvsgvp6ja4mcprjlk5vcwqzi0p1qq7b1wyi4f0g2"; }) <ins> # Fix invisible fonts with glibc 2.33: https://github.com/NixOS/nixpkgs/issues/131074 (fetchpatch { url = "https://src.fedoraproject.org/rpms/qt5-qtwebengine/raw/d122c011631137b79455850c363676c655cf9e09/f/qtwebengine-everywhere-src-5.15.5-%231904652.patch"; name = "qtwebengine-everywhere-src-5.15.5-_1904652.patch"; sha256 = "01q7hagq0ysii1jnrh5adm97vdm9cis592xr6im7accyw6hgcn7b"; }) </ins> ] ++ optionals stdenv.isDarwin [ ./qtwebengine-darwin-no-platform-check.patch ./qtwebengine-mac-dont-set-dsymutil-path.patch


Question:
Describe the bug In the 21.05 VirtualBox OVA you can download from there is no disk space available, making it impossible to use for almost anything: To Reproduce Steps to reproduce the behavior: the VirtualBox OVA from , the instructions on above page to import and start it (although the instructions are a bit outdated too, no need to log in manually) in a Konsole window Expected behavior I expect to have disk space. Here's the same for a NixOS 20.09 OVA: Screenshots ! Notify maintainers Metadata Bad nixpkgs version (21.05): Good nixpkgs version (20.09): Maintainer information:
hmm, well we can add a new option to the for the additional disk space in the image. We then could pass the value to from
I think that's setting the disk image size. Which is given here: I haven't had time to take a look, I wonder what looks like; is it a situation where fails?
Right, so assumption seems more right. Good to know.

The size of the VirtualBox base image in MiB. ''; }; <ins> baseImageFreeSpace = mkOption { type = with types; int; default = 30 * 1024; description = '' Free space in the VirtualBox base image in MiB. ''; }; </ins> memorySize = mkOption { type = types.int; default = 1536;


Question:
Describe the bug In the 21.05 VirtualBox OVA you can download from there is no disk space available, making it impossible to use for almost anything: To Reproduce Steps to reproduce the behavior: the VirtualBox OVA from , the instructions on above page to import and start it (although the instructions are a bit outdated too, no need to log in manually) in a Konsole window Expected behavior I expect to have disk space. Here's the same for a NixOS 20.09 OVA: Screenshots ! Notify maintainers Metadata Bad nixpkgs version (21.05): Good nixpkgs version (20.09): Maintainer information:
hmm, well we can add a new option to the for the additional disk space in the image. We then could pass the value to from
I think that's setting the disk image size. Which is given here: I haven't had time to take a look, I wonder what looks like; is it a situation where fails?
Right, so assumption seems more right. Good to know.

inherit pkgs lib config; partitionTableType = "legacy"; diskSize = cfg.baseImageSize; <ins> additionalSpace = cfg.baseImageFreeSpace; </ins> postVM = ''


Question:
Helvum build is broken on unstable Steps to reproduce the behavior: master helvum Build suceeds. Since it's pipewire-sys crate that fails, I suspect it was a pipewire upgrade that broke it Maintainer information:
Trying to build latest helvum master, as it's now been updated to use pipewire from Will post updates.
Alright, it fails even with the latest master, so I assume it's a pipewire error. is the maintainer of the PipeWire package and the leader of the PipeWire efforts on Nix/OS so they may know more about this. In the meantime, helvum will remain broken :(
Is it the same error? Could be that the bindings need an upgrade to support the newer version of pipewire because of changed APIs. Then that would be a bug in the pipewire-sys crate.
Yes, it's exactly the same error. You're right, I'll look into pipewire-related issues on GitLab to try and see what's going on.
I found , which means we have to wait a bit until that gets merged.
The issue links to this pull request: Not sure how it's with crates, but the dependency could be patched using this patch: (This is the alternative to waiting until that's resolved)
Sure, I'll get to work then.
Strictly speaking I'm not officially maintaining the pipewire package, but I guess I've effectively become the de facto maintainer anyway.
Sorry for mispinging you then!
No problem. I originally just wanted to get some progress and organization in the messy packaging situation. I hope that the official maintainers and autoupdate bot can take over again once upstream stabilizes more. I'm not actually sure who exactly the official maintainers would be, though. The package just says "freedesktop maintainers". EDIT: and I did end up following upstream development pretty closely so pinging me was a very reasonable guess.
as it currently stands, I don't think it's possible to override the dependency with a nix-built one. Though I have made a nix derivation for it, there's no way to propagate it to using . In turn, I'll wait and see what Ryuukyu does upstream.
I've fixed pipewire-rs and helvum and made a new release, so it should now build again once you update the package.
! Can confirm it works. Thanks

rustPlatform.buildRustPackage rec { pname = "helvum"; <del> version = "0.2.1"; </del> <ins> version = "0.3.0"; </ins> src = fetchFromGitLab { domain = "gitlab.freedesktop.org"; owner = "ryuukyu"; repo = pname; rev = version; <del> sha256 = "sha256-ZnpdGXK8N8c/s4qC2NXcn0Pdqrqr47iOWvVwXD9pn1A="; </del> <ins> sha256 = "sha256-AlHCK4pWaoNjR0eflxHBsuVaaily/RvCbgJv/ByQZK4="; </ins> }; <del> cargoSha256 = "sha256-2v2L20rUWftXdhhuE3wiRrDIuSg6VFxfpWYMRaMUyTU="; </del> <ins> cargoSha256 = "sha256-mAhh12rGvQjs2xtm+OrtVv0fgG6qni/QM/oRYoFR7U8="; </ins> nativeBuildInputs = [ clang copyDesktopItems pkg-config ]; buildInputs = [ glib gtk4 pipewire ];