jiebi/CodeConvo huggingface dataset:
Code change:
# add the same environment vars to compile.sh sed -e "/$command $/a --copt="$(echo $NIX_CFLAGS_COMPILE | sed -e 's/ /" --copt="/g')" "  -e "/$command $/a --host_copt="$(echo $NIX_CFLAGS_COMPILE | sed -e 's/ /" --host_copt="/g')" "  <ins> -e "/$command $/a --linkopt="$(echo $(< ${stdenv.cc}/nix-support/libcxx-ldflags) | sed -e 's/ /" --linkopt="/g')" "  -e "/$command $/a --host_linkopt="$(echo $(< ${stdenv.cc}/nix-support/libcxx-ldflags) | sed -e 's/ /" --host_linkopt="/g')" "  </ins> -e "/$command $/a --linkopt="-Wl,$(echo $NIX_LDFLAGS | sed -e 's/ /" --linkopt="-Wl,/g')" "  -e "/$command $/a --host_linkopt="-Wl,$(echo $NIX_LDFLAGS | sed -e 's/ /" --host_linkopt="-Wl,/g')" "  -e "/$command $/a --host_javabase='@local_jdk//:jdk' " 

Related discussion:
text: Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify 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:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in
Code change:
sys.stderr.write(msg.format(user)) return <del> basedir = os.path.join(TASKD_DATA_DIR, "keys", org, user) if os.path.exists(basedir): </del> <ins> keysdir = os.path.join(TASKD_DATA_DIR, "keys" ) orgdir  = os.path.join(keysdir       , org    ) userdir = os.path.join(orgdir        , user   ) if os.path.exists(userdir): </ins> raise OSError("Keyfile directory for {} already exists.".format(user)) <del> privkey = os.path.join(basedir, "private.key") pubcert = os.path.join(basedir, "public.cert") </del> <ins> privkey = os.path.join(userdir, "private.key") pubcert = os.path.join(userdir, "public.cert") </ins> try: <del> os.makedirs(basedir, mode=0o700) </del> <ins> # We change the permissions and the owner ship of the base directories # so that cfg.group and cfg.user could read the directories' contents. # See also: https://bugs.python.org/issue42367 for bd in [keysdir, orgdir, userdir]: # Allow cfg.group, but not others to read the contents of this group os.makedirs(bd, exist_ok=True) # not using mode= argument to makedirs intentionally - forcing the # permissions we want os.chmod(bd, mode=0o750) os.chown( bd, uid=pwd.getpwnam(TASKD_USER).pw_uid, gid=grp.getgrnam(TASKD_GROUP).gr_gid, ) </ins> certtool_cmd("-p", "--bits", CERT_BITS, "--outfile", privkey) <ins> os.chmod(privkey, 0o640) </ins> template_data = [ "organization = {0}".format(org),

Related discussion:
text: So I today I spawned a machine with and satisfyingly the directory was generated with all of the certificates etc that taskwarrior needs, including the clients' certificates. I noticed that the users' keys located at are owned by root with read only permissions for the root user alone. No matter what are and . I'd like to enable the group read those client keys, as well as the file so that I can configure a client easily. Thankfully the group can read the file, but not the client keys. The manual indeed explains that the command: Could be used to get those keys, but I'd like to use syncthing for that to automate the process even further. I got a bit lost while reading the . Specifically, I'm not sure why does always works in the following umask: I mean, ~why not~ - a solution is suggested in . A word of comment will be appreciated. cc .
Code change:
makeFlags = [ "BUILD=RELEASE" <del> "VERSION=${version}" </del> <ins> "VERSION=${version}-${src.rev}" </ins> "BINDIR=${placeholder "out"}/bin" "UDEVDIR=${placeholder "out"}/lib/udev/rules.d" "MODLDIR=${placeholder "out"}/lib/modules-load.d"

Related discussion:
text: Enabling services.hardware. (as a systemd service) breaks. Steps to reproduce the behavior: error about and several other errors like "has not been declared", "does not name a type", etc. To rebuild xow and everything else without any issues. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
The git not found problem is not fatal and the derivation overrides the version info anyway. Looks like another victim of our stdenv compiler upgrade. Looks like upstream master has a fix for that. Upstream is also orphaned so upgrading the derivation to an unstable revision is going to be needed in the short term and in the long term a replacement should probably be found. I don't have a working controller to test xow with any more so if someone wants to adopt the package, feel free to.
Code change:
''; homepage = "https://www.electroncash.org/"; platforms = platforms.linux; <del> maintainers = with maintainers; [ lassulus nyanloutre ]; </del> <ins> maintainers = with maintainers; [ lassulus nyanloutre oxalica ]; </ins> license = licenses.mit; }; }

Related discussion:
text: Describe the bug failed to build on master. To Reproduce Steps to reproduce the behavior: nixpkgs master Expected behavior It builds. 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. system: host os: multi-user?: sandbox: version: channels(root): channels(oxa): nixpkgs: Maintainer information:
Code change:
# https://github.com/NixOS/nixpkgs/issues/123851 ./fix-audio-driver-loading.patch # NOTE: both patches below should be removed when updating to 6.1.35 <del> # https://www.virtualbox.org/ticket/20914#comment:6 ./linux518.patch </del> <ins> # https://www.virtualbox.org/ticket/20914#comment:15 (fetchpatch { url = "https://www.virtualbox.org/raw-attachment/ticket/20914/vbox-linux-5.19.patch"; hash = "sha512-NNiMf8kUuM/PimrQCOacYLkrf7UFPh6ZdPsXKyLlsqWfWQXkG92Fv3qZXvg8weE1Z/SBsFTuHICEI4b4l1wZFw=="; extraPrefix = "/"; }) </ins> # https://www.virtualbox.org/ticket/20904#comment:22 ./ffreestanding.patch ];

Related discussion:
text: Virtualbox corrupts guest filesystems by randomly flipping bits when the guest writes data to the virtual hard disks. virtualbox on the host with a new virtual machine for linux 2.6/3.x/4.x with default settings (1GiB RAM, 8GiB harddisk). "Insert" a linux live medium into the virtual CD drive. The virtual hard disk should be placed on a filesystem on a physical hard disk (the bug cannot be triggered if the virtual hard disk is placed on a tmpfs, see below). the machine and open a root shell after booting. these commands inside the guest's root shell to write random data onto the hard disk, then read it back and compare it: Caution: This will overwrite anything on the guest's virtual hard disk The shown hashes should match, but in 90% of test runs, they won't. This bug makes virtualbox quite unreliable: It is still possible to install NixOS inside a virtualbox, but during installation, Nix will report a couple of checksum failures, and sometimes the installation is to be tried more then once. After that, random failures of random programs occur. If btrfs is used, this will also complain about checksum errors. After observing this on my production machine with NixOS 22.05, I tried narrowing down the offending commit. To this end, I adapted the nixpkgs minimal live cd build recipe to build an image with virtualbox installed on it, and built this agains different nixpkgs versions. So most of my tests have been performed on a test machine booted from a usb flash drive. The offending commit seems to be . I guess that commit brings in some kernel patch, which is incompatible with the way virtualbox handles disk images. The bug occurs when the host's filesystem containing the disk image is or . In both cases, I tried with freshly created filesystems. The bug does not occur if the disk image is on (or it occurs with very low probablity). I haven't tried any other filesystems on the host. Just to be sure there isn't a general problem with virtualization: I failed to reproduce the bug with qemu and a qcow2 disk image. So it seems to be a virtualbox-only problem.
Code change:
# https://github.com/NixOS/nixpkgs/issues/123851 ./fix-audio-driver-loading.patch # NOTE: both patches below should be removed when updating to 6.1.35 <del> # https://www.virtualbox.org/ticket/20914#comment:6 ./linux518.patch </del> <ins> # https://www.virtualbox.org/ticket/20914#comment:15 (fetchpatch { url = "https://www.virtualbox.org/raw-attachment/ticket/20914/vbox-linux-5.19.patch"; hash = "sha512-NNiMf8kUuM/PimrQCOacYLkrf7UFPh6ZdPsXKyLlsqWfWQXkG92Fv3qZXvg8weE1Z/SBsFTuHICEI4b4l1wZFw=="; extraPrefix = "/"; }) </ins> # https://www.virtualbox.org/ticket/20904#comment:22 ./ffreestanding.patch ];

Related discussion:
text: I observed the bug on three different machines (two desktop machines with NixOS 22.05 and NixOS 21.11, and one laptop with NixOS 21.11). I was also able to reproduce the bug with a linux live cd inside the guest. So the bug can probably be triggered by any linux in the guest. I haven't, however, tried with anything else (e.g. Windows). I was also able to reproduce the bug with a live iso based on (currently ), i.e., with virtualbox 6.1.30 (as opposed to virtualbox 6.1.34 from , currently ). By default, the virtual disk controller has it's checkmark "Use Host I/O cache" turned off in the vm config dialog. Turning it on doesn't help (). I cannot reproduce the bug with these linux kernel versions (all checked with current ) (4.19.247) (5.4.198) (5.18.4) So users of these kernel branches are safe ... until the breaking kernel patch also reaches these branches. <details<summaryFor the record: This is the build recipe I'm using for the live iso</summary<p</p</detailsMaybe I can try to bisect inside the kernel sources, but the compile-reboot-test cycle is quite slow on my machine. Strangely, I cannot find any reports about similar behaviour. The closest report might be . It would be interesting for me if this bug can be reproduced/verified by someone else. I'm not sure if this should be considered a kernel bug (the kernel should probably not change the way disk writes are handled), or a virtualbox bug (at the moment I don't know of any other software affected). kernel maintainer team: virtualbox maintainer: (by the way: I'm surprised there's only one maintainer for virtualbox. Thanks for your good work, ; I'm a heavy user!) This is my production system, which also shows that bug. But I did most of the tests to reproduce the bug and narrow down the cause with live iso images based on current ().
I bisected the linux kernel tree to find as the cause for the guest data corruption. Googling the commit's hash leads to this issue in the VirtualBox bug tracker.
Code change:
# https://github.com/NixOS/nixpkgs/issues/123851 ./fix-audio-driver-loading.patch # NOTE: both patches below should be removed when updating to 6.1.35 <del> # https://www.virtualbox.org/ticket/20914#comment:6 ./linux518.patch </del> <ins> # https://www.virtualbox.org/ticket/20914#comment:15 (fetchpatch { url = "https://www.virtualbox.org/raw-attachment/ticket/20914/vbox-linux-5.19.patch"; hash = "sha512-NNiMf8kUuM/PimrQCOacYLkrf7UFPh6ZdPsXKyLlsqWfWQXkG92Fv3qZXvg8weE1Z/SBsFTuHICEI4b4l1wZFw=="; extraPrefix = "/"; }) </ins> # https://www.virtualbox.org/ticket/20904#comment:22 ./ffreestanding.patch ];

Related discussion:
text: According to the information therein, the bug only occurs on some CPU models. The issue there also contains two patches: from This one fixes the problem on linux 5.18. It got already included in nixpkgs' master branch with . It is on it's way to being backported to NixOS 22.05 with . Note that this patch contains several clauses and does not fix the problem on earlier LTS kernel versions. from This one fixes the problem on linux 5.18+, but also on LTS kernel versions. I tested the following combinations with (currently on , where VirtualBox 6.1.34 with and linux 5.15.51 are used by default): VirtualBox version & patch 5.18.8 -----------------------------:------: 6.1.34 + OK 6.1.34 + OK I also tested the following combinations with (currently on , where VirtualBox 6.1.30 and linux 5.15.49 are used by default): VirtualBox version & patch 5.18.6 -----------------------------:------------: 6.1.30 won't build 6.1.34 + OK 6.1.34 + OK To replace VirtualBox 6.1.30 with 6.1.34, I cherry-picked . All tests have been performed on an Intel Core i5-4460 as host, by repeatedly writing/reading 4GiB of random data onto/from a virtual hard disk. Based on these tests, I suggest to use VirtualBox 6.1.34 with the in NixOS 22.05 and in NixOS unstable, as currently, both channels will exhibit the bug in their default configurations (i.e., with kernel 5.15). I will submit a pull request for master shortly.
Code change:
}; config = mkIf cfg.enable { <del> networking.firewall.extraCommands = '' ${pkgs.bash}/bin/bash -x ${pkgs.miniupnpd}/etc/miniupnpd/iptables_init.sh -i ${cfg.externalInterface} ''; </del> <ins> networking.firewall.extraCommands = lib.mkIf (firewallScripts != []) (builtins.concatStringsSep "n" (map (fw: '' EXTIF=${cfg.externalInterface} ${pkgs.bash}/bin/bash -x ${miniupnpd}/etc/miniupnpd/${fw}_init.sh '') firewallScripts)); networking.firewall.extraStopCommands = lib.mkIf (firewallScripts != []) (builtins.concatStringsSep "n" (map (fw: '' EXTIF=${cfg.externalInterface} ${pkgs.bash}/bin/bash -x ${miniupnpd}/etc/miniupnpd/${fw}_removeall.sh '') firewallScripts)); </ins> <del> networking.firewall.extraStopCommands = '' ${pkgs.bash}/bin/bash -x ${pkgs.miniupnpd}/etc/miniupnpd/iptables_removeall.sh -i ${cfg.externalInterface} ''; </del> <ins> networking.nftables = lib.mkIf (firewall == "nftables") { # see nft_init in ${miniupnpd-nftables}/etc/miniupnpd tables.miniupnpd = { family = "inet"; # The following is omitted because it's expected that the firewall is to be responsible for it. # # chain forward { #   type filter hook forward priority filter; policy drop; #   jump miniupnpd # } # # Otherwise, it quickly gets ugly with (potentially) two forward chains with "policy drop". # This means the chain "miniupnpd" never actually gets triggered and is simply there to satisfy # miniupnpd. If you're doing it yourself (without networking.firewall), the easiest way to get # it to work is adding a rule "ct status dnat accept" - this is what networking.firewall does. # If you don't want to simply accept forwarding for all "ct status dnat" packets, override # upnp_table_name with whatever your table is, create a chain "miniupnpd" in your table and # jump into it from your forward chain. content = '' chain miniupnpd {} chain prerouting_miniupnpd { type nat hook prerouting priority dstnat; policy accept; } chain postrouting_miniupnpd { type nat hook postrouting priority srcnat; policy accept; } ''; }; }; </ins> systemd.services.miniupnpd = { description = "MiniUPnP daemon"; after = [ "network.target" ]; wantedBy = [ "multi-user.target" ]; serviceConfig = { <del> ExecStart = "${pkgs.miniupnpd}/bin/miniupnpd -f ${configFile}"; </del> <ins> ExecStart = "${miniupnpd}/bin/miniupnpd -f ${configFile}"; </ins> PIDFile = "/run/miniupnpd.pid"; Type = "forking"; };

Related discussion:
text: We already have in , but only with iptables support. It would be nice to have the nftables version available as well.
Being worked on in , I'm trying to test myself but couldn't make it to work yet.
I think the PR is ready now, testing welcome!
Maybe add an option for will be better?
Code change:
stdenv.mkDerivation rec { pname = "tiramisu"; <del> version = "2.0.20211107"; </del> <ins> # FIXME: once a newer release in upstream is available version = "2.0-unstable-2023-03-29"; </ins> src = fetchFromGitHub { owner = "Sweets"; <del> repo = pname; rev = version; sha256 = "1n1x1ybbwbanibw7b90k7v4cadagl41li17hz2l8s2sapacvq3mw"; </del> <ins> repo = "tiramisu"; # FIXME: use the current HEAD commit as upstream has no releases since 2021 rev = "5dddd83abd695bfa15640047a97a08ff0a8d9f9b"; hash = "sha256-owYk/YFwJbqO6/dbGKPE8SnmmH4KvH+o6uWptqQtpfI="; </ins> }; buildInputs = [ glib ];

Related discussion:
text: The project seems slow with releasing the latest changes, which (among other things) includes Package name: tiramisu Latest released version: 2.0., I suggest using the latest commit instead since there is no newer release yet <!-- Search your package here: --- Current version on the unstable channel: 2.0. Current version on the stable/release channel: 2.0. <!-- 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! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.
Code change:
''; }; <del> extraConfig = mkOption { type = types.lines; default = ""; </del> <ins> settings = mkOption { type = ini.type; default = {}; </ins> description = '' <del> Configuration appended to the generated NetworkManager.conf. </del> <ins> Configuration added to the generated NetworkManager.conf, note that you can overwrite settings with this. </ins> Refer to [ https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html

Related discussion:
text: Describe the bug NetworkManager is a particularly important component and we don't have any tests for it that could block a channel advance. In particular, a change can happen on nixos-unstable leaving users without functioning networking, and while rollbacks are possible it isn't an excuse to allow that to reach production systems. NixOS doesn't produce either. Manual testing is also cumbersome if we want to make a new stable release. Upstream NetworkManager does have some integration testing but obviously not useful to us. I think to start, if we at least had a test that verifies the services start without issues would be great.
Agreed. While developing tests for the multipath TCP module I was surprised to see no networkmanager module. I had some difficulties with the nixos test infrastructure at first because the test infra will by default install a slirp interface () and it messed up the interface naming. Like I would clear but interfaces would still be named starting from instead of . Just thought I would mention it in case the brave soul writing the test is interested in multihoming. (but that's more a concern I have with the test infra).
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Bleh.
I marked this as stale due to inactivity. &rarr;
consequences of our inactions
Code change:
, autoPatchelfHook , alsa-lib , cups <ins> , libpulseaudio </ins> , libX11 , libXScrnSaver , libXtst

Related discussion:
text: Trying to install tetrio fails (see screenshots) Steps to reproduce the behavior: tetrio-desktop from nixpkgs-unstable (I did it using a flake) The package should install with no errors. ! <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
Oops, it looks like I accidentally used a non-direct download link for the source. It also looks like audio is broken, so I'll start a PR soon.
Code change:
buildInputs = [ libpcap ndn-cxx openssl websocketpp ] ++ lib.optional withSystemd systemd; wafConfigureFlags = [ <del> "--boost-includes=${boost.dev}/include" "--boost-libs=${boost.out}/lib" </del> <ins> "--boost-includes=${boost175.dev}/include" "--boost-libs=${boost175.out}/lib" </ins> "--with-tests" ] ++ lib.optional (!withWebSocket) "--without-websocket";

Related discussion:
text: The default boost version has been bumped from 1.69 (or 1.75) to 1.77. This is a notice for maintainers that the following packages are now failing to build: - - - - - - - - - - [x] cryfs A typical fix would involve pinning the package to a specific version (e.g. see )
My fix in is not the same as . Is there a very good reason to prefer one over the other ?
Well, I like trying to keep it away from the huge top-level file. (which is e.g. harder to use in git)
Re. pivx, I think we should mark it broken. Our current version is very old (and therefore useless), and the new version includes a rust build. I don't have the capacity to fix this ATM.
In my case, what broke it was the update from boost175 to boost177. Fix is in .
It's in the branch now, so please target any further fixes there as well (unless they're a mass rebuild, etc.)
colobot fixed with
FYI, ledger has some broken behavior with the new boost version, although it curiously doesn't cause a test failure: ledger/ledger.
Our expression does not attempt to run tests.
Ah, that would be why, thanks. Nevertheless, the binary exhibits the same problem described in that issue in interactive use.
Code change:
# stray test failure doCheck = false; <ins> nativeBuildInputs = stdenv.lib.optionals stdenv.isDarwin [ shortenPerlShebang ]; </ins> buildInputs = [ ArchiveZip ArchiveCpio file ]; perlPostHook = ''

Related discussion:
text: Describe the bug doesn't run on Darwin, due to some Perl / shebang errors. To Reproduce Steps to reproduce the behavior: Darwin, run the only produced binary , ie. following output is produced: Expected behavior The executable should output its help text when run without arguments: Additional context I managed to get it running using a wrapper script that runs . Notify maintainers Metadata Maintainer information: