jiebi/CodeConvo huggingface dataset:
Change:
machine.wait_for_unit("phpfpm-foobar.service") # Check so we get an evaluated PHP back <del> assert "PHP Version ${pkgs.php.version}" in machine.succeed("curl -vvv -s http://127.0.0.1:80/") </del> <ins> response = machine.succeed("curl -vvv -s http://127.0.0.1:80/") assert "PHP Version ${pkgs.php.version}" in response, "PHP version not detected" </ins> # Check so we have database and some other extensions loaded <del> assert "json" in machine.succeed("curl -vvv -s http://127.0.0.1:80/") assert "opcache" in machine.succeed("curl -vvv -s http://127.0.0.1:80/") assert "pdo_mysql" in machine.succeed("curl -vvv -s http://127.0.0.1:80/") assert "pdo_pgsql" in machine.succeed("curl -vvv -s http://127.0.0.1:80/") assert "pdo_sqlite" in machine.succeed("curl -vvv -s http://127.0.0.1:80/") </del> <ins> for ext in ["json", "opcache", "pdo_mysql", "pdo_pgsql", "pdo_sqlite"]: assert ext in response, f"Missing {ext} extension" </ins> ''; })

Discussion:
Describe the bug When I enable PHP in httpd using , the file when visited can only see 11 extensions instead of the 52 I get when I run it through php CLI command. To Reproduce A failing NixOS test: Additional context Likely caused by the great refactor: Notify maintainers
Yep, the refactor relies on a configuration file with all the extensions to load being present and specified. For the binary, we have a wrapper that just tells PHP to look in the right folder for the config, but with the module, it looks like that's not used, since it loads PHP as an extension. The solution would probably be to inherit the config from the package as the first thing put into the it already generates; it should be accessible as .
Change:
sha256 = "1kzrgqaclfk6gcwhknxn28xl74gm5swipgn8kk8avacb4nsw1l9q"; }; <ins> patches = [ # XXX: REMOVE ON NEXT VERSION BUMP # Fixes compatibility of the bluetooth and network modules with linux kernel # >=5.11 # c.f. https://github.com/Alexays/Waybar/issues/994 (fetchpatch { url = "https://patch-diff.githubusercontent.com/raw/Alexays/Waybar/pull/1015.patch"; sha256 = "sha256-jQZEM3Yru2yxcXAzapU47DoAv4ZoabrV80dH42I2OFk="; }) ]; </ins> nativeBuildInputs = [ meson ninja pkg-config scdoc wrapGAppsHook cmake ] ++ lib.optional withMediaPlayer gobject-introspection;

Discussion:
Describe the bug crash on startup To Reproduce Steps to reproduce the behavior: example config: example waybar: Expected behavior Normal application startup. No crash. Notify maintainers Metadata Maintainer information:
Same issue here.
This seems like an upstream issue: and will be fixed in the next release: Could you test with waybar master? Recommended temporary solution is to disable the and module.
Waybar master is available as an overlay/package from :smile:
Tested the master version and it fixed the problems for me. Thank you.
Change:
overlays, crossOverlays ? [ ], # Allow passing in bootstrap files directly so we can test the stdenv bootstrap process when changing the bootstrap tools <del> bootstrapFiles ? </del> <ins> bootstrapFiles ? (config.replaceBootstrapFiles or lib.id) ( </ins> if localSystem.isAarch64 then import ./bootstrap-files/aarch64-apple-darwin.nix else <del> import ./bootstrap-files/x86_64-apple-darwin.nix, </del> <ins> import ./bootstrap-files/x86_64-apple-darwin.nix ), </ins> }: assert crossSystem == localSystem;

Discussion:
Today provides an outdated set of : Specifically I keep hitting on any attempts to rebuild 32-bit packages. Currently I am patching the to provide the working tools built locally: I think it would be generally useful to be able to pass non-default tools for workaround purposes and testing purposes of new tools. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
people who want this, can you review
Change:
"d ${cfg.statePath} 0750 ${cfg.user} ${cfg.group} -" "d ${cfg.statePath}/builds 0750 ${cfg.user} ${cfg.group} -" "d ${cfg.statePath}/config 0750 ${cfg.user} ${cfg.group} -" <ins> "d ${cfg.statePath}/config/initializers 0750 ${cfg.user} ${cfg.group} -" </ins> "d ${cfg.statePath}/db 0750 ${cfg.user} ${cfg.group} -" "d ${cfg.statePath}/log 0750 ${cfg.user} ${cfg.group} -" "d ${cfg.statePath}/repositories 2770 ${cfg.user} ${cfg.group} -"

Discussion:
Describe the bug Clean Gitlab installs appeas to be broken, judging from the test Describe the bug During initialization: The cause appears to be because reinserting the tmpfiles line with the "D" rule for the initializers directory makes it work. cc -- it looks to me like this never worked with fresh installs? To Reproduce
Since was merged, I am also receiving an error that the systemd service pre-start script can't run the command: It is referencing two copies of the same application config file, in both the nix store and . It also seems to be caused by the changes in either or
Change:
install -Dm644 assets/micro-logo-mark.svg $out/share/icons/hicolor/scalable/apps/micro.svg ''; <del> postFixup = let clipboardPackages = lib.optionals withXclip [ xclip ] ++ lib.optionals withWlClipboard [ wl-clipboard ]; in lib.optionalString (withXclip || withWlClipboard) '' wrapProgram "$out/bin/micro"  --prefix PATH : "${lib.makeBinPath clipboardPackages}" ''; </del> passthru = { tests = lib.packagesFromDirectoryRecursive { inherit callPackage; directory = ./tests; }; <ins> wrapper = callPackage ./wrapper.nix { micro = self; }; </ins> }; meta = {

Discussion:
The current package depends on wayland/x11, making its use in servers unnecessarily cumbersome. This is nothing a simple overlay can't help with, but that requires building the package from source and is yet another thing to learn for newbies (plus, some may not notice the dependencies and inadvertently end up putting wayland on their servers... ask me how I know :wink:). Would a separate (or similar name) package be worth it? (possibly, together with some options?) mantainers: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
We have no explicit policy prohibiting green aliases. I will create something about this. On the other hand I do not see why creating a dedicated NixOS module for it - at least not now. You can merely throw it at environment.systemPackages and the effect will be the same.
concurrent effort ^
/ I would suggest a huge load of modifications in your idea, so here is my implementation:
Change:
cp -r *.app $out/Applications mkdir -p $out/bin <del> makeWrapper $out/Applications/Google Chrome.app/Contents/MacOS/Google Chrome $out/bin/google-chrome-stable  --add-flags ${ lib.concatStringsSep " " [ (lib.escapeShellArg commandLineArgs) # Disables auto updates and browser outdated popup "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'" ] } </del> <ins> # "--simulate-outdated-no-au" disables auto updates and browser outdated popup makeWrapper $out/Applications/Google Chrome.app/Contents/MacOS/Google Chrome $out/bin/google-chrome-stable  --add-flags "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'"  --add-flags ${lib.escapeShellArg commandLineArgs} </ins> runHook postInstall ''; });

Discussion:
Steps to reproduce the behavior: (add) google-chrome from nixpkgs/master (the exact commit with problem from this issue ) Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I tryed both default nix and nix.package = ;
Oops, that's odd, it passed all the eval checks on the original PR I thought. I've created to fix.
Change:
inherit pkgs lib config; partitionTableType = "legacy"; diskSize = cfg.baseImageSize; <ins> additionalSpace = cfg.baseImageFreeSpace; </ins> postVM = ''

Discussion:
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.
Change:
sha256 = "06cwhimm71safmwvp6nhxp6hvxsg62whnbgbgiflsqb8mgg40n7n"; }; <del> # The hardcoded list of allowed system calls for seccomp is # insufficient for NixOS, add more to make it work (issue #21136). patches = [ ./seccomp.patch ]; </del> configureFlags = [ "--sysconfdir=/etc" "--localstatedir=/var"

Discussion:
ntpd is killed shortly after start. strace ends with: 950 select(23, [16 17 18 19 20 21 22], NULL, NULL, NULL) = 1 (in [19]) 950 recvmsg(19, {msgname={safamily=AFINET, sinport=htons(123), sinaddr=inetaddr("x.x.x.x")}, msgnamelen=28 =16, msgiov=[{iovbase="..."..., iovlen=2120}], msgiovlen=1, msgcontrol=[{cmsglen=32, cmsglevel=SOLSOCKET, cmsgtype=SOTIMESTAMPNSOLD, cmsgdata={tvsec=, tvnsec=}}], msgcontrollen=32, msgflags=0}, 0) = 48 950 recvmsg(19, {msgnamelen=28}, 0) = -1 EAGAIN (Resource temporarily unavailable) 950 clockadjtime(CLOCKREALTIME, <unfinished ...) = ? 950 +++ killed by SIGSYS (core dumped) +++ After adding clockadjtime to , ntpd proceeds after the call to clockadjtime(). Updated is attached. Use this config: = { enable = true; servers = [ "x.x.x.x" ]; extraFlags = [ "-g" ]; }; Do not crash. glibc changed the implementation of adjtimex to use clock_adjtime: ;a=commit;h=
There have been multiple reported regressions introduced by NTP's seccomp "support" over the years, e.g. and , now this, and several others I'm sure we're missing. While it's hilarious for me (a lazy maintainer) to say so, I'm getting a bit tired of it. Out of curiosity since this seems like a trend, I note that the patch for this original change in glibc was from 2019. Why did it take this long for this to percolate downstream, and why is there not an ntp patch for it already upstream? I did not find a historical answer to this, but I suspect no concrete one exists; it's probably a number of things leading to this. Either way, it isn't ideal for an almost 2-year old patch to suddenly be busting an extremely common daemon.

Let's also look at the seccomp filter itself: it basically enables , including some that seemingly have no reason at all for being here. You can do everything with this syscall list from write reverse-proxies to normal open/read/write/close on files. On top of that, from glancing at the , I cannot see a single security flaw that would have been mitigated by this filter in any way. But I might have missed something. Finally, didn't have much to say in support of NTPd, either. The actual award would go to chrony, which on top of that, also supports NTS (like ntpsec) and even supports features like PTP for highly accurate virtualized clocks, in addition to its normal time keeping duties being more accurate, too. My actual inclination, in light of all this, is not to add another patch to , it's to turn off seccomp support for ntpd entirely, and in the long run, deprecate and remove all alternatives in favor of chrony. Users who want to sport their own favorite-flavour NTP daemon can handle these issues on their own.
Maybe --enable-libseccomp isn't used by many. At least, CentOS, Slackware, Arch and Debian don't seem to use it. See Fine for me.
Fedora didn't have it enabled either back when they used ntp (they've switched to ntpsec)
Change:
mkDerivation rec { pname = "kdiff3"; <del> version = "1.10.5"; </del> <ins> version = "1.10.6"; </ins> src = fetchurl { url = "https://download.kde.org/stable/${pname}/${pname}-${version}.tar.xz"; <del> sha256 = "sha256-2wMm0khBGnqaxBMBx/8O83ecvwQKMw/yhQDdwtTxjIw="; </del> <ins> hash = "sha256-EzOu+dZjbGs0ZqF/0sXZbpGdTrUh6isjUoJUETau+zE="; </ins> }; buildInputs = [ boost ];

Discussion:
KDiff3 produces a segmentation fault on quitting instead of exiting cleanly. This makes it unusable as a Git mergetool, because it always reports failure. Steps to reproduce the behavior: a terminal, run the file-selection dialog. the "Quit" command via either <kbdCtrl+Q</kbdor the menu File-Quit Kdiff3 exits cleanly (exit code ) and without errors. This is a regression in , as the issue is not present in .
Indeed. I'll need to take a look.
Change:
<ins> { lib , python3Packages , fetchPypi , ffmpeg-headless , rtmpdump , atomicparsley , atomicparsleySupport ? true , ffmpegSupport ? true , rtmpSupport ? true , withAlias ? false # Provides bin/youtube-dl for backcompat , update-python-libraries }: python3Packages.buildPythonApplication rec { pname = "yt-dlp"; # The websites yt-dlp deals with are a very moving target. That means that # downloads break constantly. Because of that, updates should always be backported # to the latest stable release. version = "2024.7.25"; pyproject = true; src = fetchPypi { inherit version; pname = "yt_dlp"; hash = "sha256-dYeqJeI2z3sUvbk3i7//9RIC2QGwQgK+DPYsu1bTtSw="; }; build-system = with python3Packages; [ hatchling ]; dependencies = with python3Packages; [ brotli certifi curl-cffi mutagen pycryptodomex requests secretstorage  # "optional", as in not in requirements.txt, needed for `--cookies-from-browser` urllib3 websockets ]; # Ensure these utilities are available in $PATH: # - ffmpeg: post-processing & transcoding support # - rtmpdump: download files over RTMP # - atomicparsley: embedding thumbnails makeWrapperArgs = let packagesToBinPath = [] ++ lib.optional atomicparsleySupport atomicparsley ++ lib.optional ffmpegSupport ffmpeg-headless ++ lib.optional rtmpSupport rtmpdump; in lib.optionals (packagesToBinPath != []) [ ''--prefix PATH : "${lib.makeBinPath packagesToBinPath}"'' ]; setupPyBuildFlags = [ "build_lazy_extractors" ]; # Requires network doCheck = false; postInstall = lib.optionalString withAlias '' ln -s "$out/bin/yt-dlp" "$out/bin/youtube-dl" ''; passthru.updateScript = [ update-python-libraries (toString ./.) ]; meta = with lib; { homepage = "https://github.com/yt-dlp/yt-dlp/"; description = "Command-line tool to download videos from YouTube.com and other sites (youtube-dl fork)"; longDescription = '' yt-dlp is a youtube-dl fork based on the now inactive youtube-dlc. youtube-dl is a small, Python-based command-line program to download videos from YouTube.com and a few more sites. youtube-dl is released to the public domain, which means you can modify it, redistribute it or use it however you like. ''; changelog = "https://github.com/yt-dlp/yt-dlp/releases/tag/${version}"; license = licenses.unlicense; maintainers = with maintainers; [ mkg20001 SuperSandro2000 ]; mainProgram = "yt-dlp"; }; } </ins>

Discussion:
yt-dlp doesnt work with curl-impersonate Steps to reproduce the behavior: my to see targets available n/a the example in curl-impersonate repository works Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
}; virt-manager-qt = libsForQt5.callPackage ../applications/virtualization/virt-manager/qt.nix { <del> qtermwidget = lxqt.qtermwidget; </del> <ins> qtermwidget = lxqt.qtermwidget_1_4; </ins> }; virtscreen = callPackage ../tools/admin/virtscreen { };

Discussion:
Steps to reproduce the behavior: virt-manager-qt on 24.05 (or, I assume, unstable) Full log: Bisecting the build yields from as the first bad commit. It updates from to . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Relevant upstream commit:
Change:
"-DgRPC_SSL_PROVIDER=package" "-DgRPC_PROTOBUF_PROVIDER=package" "-DgRPC_GFLAGS_PROVIDER=package" <ins> "-DBUILD_SHARED_LIBS=ON" </ins> ]; # CMake creates a build directory by default, this conflicts with the

Discussion:
If I try to use the grpc package from the current unstable channel, then this builds only the static libraries. I tried to add to the , then cmake tries to build the shared libraries, but fails with the following error: Maybe this is an grpc issue?
I could fix it for me. The build creates a executable, which is linked to . This executable gets then used by protbuf as a plugin to build other stuff. If it gets statically linked, everythings works. But as I try to build it dynamically, it doesn't find the library when protbuf gets executed with the plugin. So I add a hook to set the . Maybe there is a better solution, but this works for me.
Change:
<del> { stdenvNoCC, lib, fetchurl, undmg, version , sha256 }: let pname = "losslesscut"; nameRepo = "lossless-cut"; nameCamel = "LosslessCut"; nameSource = "${nameCamel}-mac-x64.dmg"; nameApp = nameCamel + ".app"; owner = "mifi"; src = fetchurl { url = "https://github.com/${owner}/${nameRepo}/releases/download/v${version}/${nameSource}"; name = nameSource; inherit sha256; }; in stdenvNoCC.mkDerivation { inherit pname version src; nativeBuildInputs = [ undmg ]; unpackPhase = '' undmg ${src} ''; sourceRoot = nameApp; installPhase = '' mkdir -p $out/Applications/${nameApp} cp -R . $out/Applications/${nameApp} ''; meta.platforms = lib.platforms.darwin; } </del>

Discussion:
Losslesscut crashes at startup due to missing Steps to reproduce the behavior: # crash # works Losslesscut works out-of-the-box. probably just needs a in .
It seems to come from a sandboxing feature of Chromium. (LosslessCut is an Electron app, and Electron uses Chromium, IIUC.) I'll add the flag when I'm available. Should it be to both the Linux and the Darwin binary, or just to the former?
I was only able to test on Linux. While you're at it: When bumping the version, filenames need a change (only tested for Linux): and is still open.
Thank you for reminding! After a quick test, 3.43.0 does run out-of-the-box on my machine Does it crash because the user namespaces is unavailable? Does the same problem happen to , it is another electron app packaged the same way. Does it happen to itself?
I can confirm that it works ootb on NixOS 21.11, but not on 22.05. Caprine crashes in a similar way on NixOS 22.05: Chromium works on both.
How about onlyoffice-bin? If does work, it might have something to do with .
works on 22.05
I'm working on it, but couldn't find a way to call in . To be exact, I don't know how to inject the dependency , a setup hook, into the builder. How should I do it? Thanks a lot for your patience.
Is this issue still relevant?
Last time I checked: Yes. I've got this still on my list and will close in case it is resolved.
It should now be fixed in .
Confirmed.
Change:
<ins> { stdenv, buildPythonPackage, fetchPypi, isPyPy, unittest2 }: buildPythonPackage rec { pname = "pyflakes"; version = "1.5.0"; name = "${pname}-${version}"; src = fetchPypi { inherit pname version; sha256 = "1x1pcca4a24k4pw8x1c77sgi58cg1wl2k38mp8a25k608pzls3da"; }; buildInputs = [ unittest2 ]; doCheck = !isPyPy; meta = with stdenv.lib; { homepage = https://launchpad.net/pyflakes; description = "A simple program which checks Python source files for errors"; license = licenses.mit; maintainers = with maintainers; [ garbas ]; }; } </ins>

Discussion:
Flake8 with Python 3.6 fails to build with System: 17.09pre106916. (Hummingbird) Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: 17.09pre106916. Sandboxing enabled: build-use-sandbox = false
Try upgrading the pyflakes expression to the latest version
I can produce this same problem using nixpkgs commit (latest master as of this writing).
Change:
wayst = callPackage ../applications/terminal-emulators/wayst { }; wezterm = darwin.apple_sdk_11_0.callPackage ../applications/terminal-emulators/wezterm { <del> inherit (darwin.apple_sdk_11_0.frameworks) Cocoa CoreGraphics Foundation UserNotifications; </del> <ins> inherit (darwin.apple_sdk_11_0.frameworks) Cocoa CoreGraphics Foundation UserNotifications System; </ins> }; x3270 = callPackage ../applications/terminal-emulators/x3270 { };

Discussion:
Steps to reproduce the behavior: for , on MacOS Ventura (13.3.x) Tested builds on both a and an and got the same error. Metadata was obtained on an machine compiling for both architectures, as x86 Darwin can be compiled for on Apple Silicon. Please run and paste the result.
No idea and I am not really motivated to dig into why this is broken myself. If someone figures it out, please fill a PR and I'll take a look at it.
FYI, the sdk versions may be bad.
We are using the 11 sdk since maybe some dependency also needs to be linked against that version? /cc
Is there a way to choose the binary package instead of building from source?
I am having the same issue since I last updated my flakes.
On MacOS you can download the wezterm binary from their page.
Until this is fixed I've replaced the derivation with the . Working great so far.
Change:
sha256bin64 = "1m8vv3qh79an3719afz7n2ijqanf4cyxz2q4bzm512x52z5zipl7"; }; stable = { <del> version = "46.0.2490.71"; sha256 = "1dnwhwvn39x8lm1jszjn8y7vy478zy75gm696rr2dvk4kqj1hjyd"; sha256bin32 = "1v1acg32dzmkydzy7sh6xjbzqar052iw8x8hql2yjz5kxznir4sf"; sha256bin64 = "15ladhxiym760mid5zq09vp73irzwlp31br9yqslzgv4460ma3np"; </del> <ins> version = "45.0.2454.101"; sha256 = "1yw5xlgy5hd3iwcyf0sillq5p367fcpvp4mizpmv52cwmv52ss0v"; sha256bin32 = "1ll8lmkmx7v74naz1vcnrwk5ighh0skfcb66jkq4kgxrb5fjgwm5"; sha256bin64 = "1cwbd3n77dnbfnrfr8g0qng9xkgvz6y7mx489gpx1wsamgi42bzj"; </ins> }; }

Discussion:
sites like and google hangouts crash the content process within chromium, it has also been mentioned on the irc channel
I've confirmed that it's not coming from . Checking to see if it's . cc
I've confirmed that is the culprit. Shall we revert?
fwiw I have had this problem with beta channel chromium too for at least several weeks. I'm currently on version 46.0.2490.64, but it definitely applied to other versions. Is there an upstream bug that anyone has seen for this?
This seems related: I guess there might be some issue getting /dev/urandom from inside chromium's sandbox, see: and
If is indeed our issue, then the problem is that we don't have OpenSSL enabled. Looks like it was disabled by and replaced by NSS. do you want to comment on whether re-enabling is a good idea?
Looks like another solution might be to apply this patch: EDIT: Ooops, I realize I just paraphrased
OpenSSL was more or less officially supported at the time I created the Chromium source build but it was broken by upstream on a regular basis, so I switched to NSS. It however seems to have changed, see the the following document: I'm working on Chromium this week, so I'll investigate and test this as well.
Wouldnt it make more sense to just use the bundled boringssl for chromium? aszlig wrote:
Maybe, as said, I have to catch up on all those Chromium issues these days anyway, so I'll investigate. Using as much system dependencies as possible has the advantage that it cuts down build time, so we might want to avoid using more bundled dependencies.
But it has the major disadvantage of not being tested by upstream chromium developers. I think in the case chromium where we have a solid security story for bundled dependencies, we should use bundling as it provides more stability. I have a hunch that we arent saving more than 10% (although probably far less) build time by providing our own dependencies anyway. It would be worth investigating what that breakdown actually looks like. aszlig wrote:
thanks for fixing this in !
: As this issue is fixed, would one of you mind to close this bug ?
yeah, srtp works great on 47 and 48