jiebi/CodeConvo huggingface dataset:
Code change:
cpu = [ ]; }; by-spec."bower2nix"."*" = <del> self.by-version."bower2nix"."3.0.1"; by-version."bower2nix"."3.0.1" = self.buildNodePackage { name = "bower2nix-3.0.1"; version = "3.0.1"; </del> <ins> self.by-version."bower2nix"."3.1.1"; by-version."bower2nix"."3.1.1" = self.buildNodePackage { name = "bower2nix-3.1.1"; version = "3.1.1"; </ins> bin = true; src = fetchurl { <del> url = "https://registry.npmjs.org/bower2nix/-/bower2nix-3.0.1.tgz"; name = "bower2nix-3.0.1.tgz"; sha1 = "06a52c033a66a890fb0c7c45a43074f3bc2e4a44"; </del> <ins> url = "https://registry.npmjs.org/bower2nix/-/bower2nix-3.1.1.tgz"; name = "bower2nix-3.1.1.tgz"; sha1 = "wfzj1k6jkfnk1bkgbmpni59mdab8zk3p"; </ins> }; deps = { "argparse-1.0.4" = self.by-version."argparse"."1.0.4";

Related discussion:
text: fetch-bower produces truncated nix-store entry when run under nix-build: Looking into the retrieved jquery in the nix store you can see jquery is actually missing: It works fine when trying to manually run it as a regular user: bower- generated by : run nix-build System: (16.09beta172. (Flounder)) Nix version: (nix-env (Nix) 1.11.4) Nixpkgs version: (16.09beta172.)
ping
Sorry for the delay I will test and merge today.
Hello thanks for your detailed report. I am getting slightly different results to you, so more investigation will be necessary. In my environment (NixOS 16.09 channel), there was no hash mismatch. Possibly something caused git to fail to download the jquery package. If it silently fails producing an incorrect result, then that is a bug in bower2nix which could be reported at
I am not sure this due to bower2nix. Fetch-bower is calling git and should handle the error's accordingly, no?
It consistently fails for me both on the latest unstable and 16.09 channels. Can you try updating your channels? My suspect was commit but I wasn't able to revert it cleanly to try it out.
By , I also mean . I have rolled the two programs into one repo. You are definitely right, is calling (indirectly, through the API), and should handle the error. I'm an avid subscriber to 16.09 and especially nixos-unstable, so have tested on those. Obviously it would be easier to fix the error handling if I can make fail myself. Do you have any further info about your setup which might be relevant? E.g. any proxy settings required for git to work. Can I also confirm that you are running before retrying ?
I don't have any proxy settings. Is it possible GitHub is rate limiting requests from bower? I found this thread interesting And yes I am running nix-store --delete before trying nix-build.
Hi are there any additional details I can provide? I am not that familiar with typescript or javascript, but I could try to narrow the issue down with some help.
How to reproduce: Expected output: bower package info json.
Code change:
cpu = [ ]; }; by-spec."bower2nix"."*" = <del> self.by-version."bower2nix"."3.0.1"; by-version."bower2nix"."3.0.1" = self.buildNodePackage { name = "bower2nix-3.0.1"; version = "3.0.1"; </del> <ins> self.by-version."bower2nix"."3.1.1"; by-version."bower2nix"."3.1.1" = self.buildNodePackage { name = "bower2nix-3.1.1"; version = "3.1.1"; </ins> bin = true; src = fetchurl { <del> url = "https://registry.npmjs.org/bower2nix/-/bower2nix-3.0.1.tgz"; name = "bower2nix-3.0.1.tgz"; sha1 = "06a52c033a66a890fb0c7c45a43074f3bc2e4a44"; </del> <ins> url = "https://registry.npmjs.org/bower2nix/-/bower2nix-3.1.1.tgz"; name = "bower2nix-3.1.1.tgz"; sha1 = "wfzj1k6jkfnk1bkgbmpni59mdab8zk3p"; </ins> }; deps = { "argparse-1.0.4" = self.by-version."argparse"."1.0.4";

Related discussion:
text: Actual output: nothing, not even an error message.
This problem is back. I can reproduce it by following the steps outlined in the top message. (latest nixpkgs-unstable) It did work for me a while ago though, so it looks like a regression. Did some digging around but I cannot figure it out. cc
Good catch, I think I've seen the same issue as well, but didn't bother (lack of time). Could be a different cause, but we have to start somewhere :)
Running produces correct result while -ing the following produces an output without jquery (just meta data)
Figured it out. Git doesn't see SSL certificates. I made it run with this expression I'll try to open a PR to fix this in nixpkgs. I'll also try to open a PR to bower2nix because there is a bug in it - missing SSL cert should not result in exit code 0.
Code change:
"aarch64-linux" = { platformStr = "linuxarm64"; projectArch = "arm64"; <del> sha256 = "01ny1k10dklsqrrqmxqd9433413wmpk4ddsmkjp9dzv52dvpcl08"; </del> }; "i686-linux" = { platformStr = "linux32"; projectArch = "x86"; <del> sha256 = "000j6pc336c43xczl1rs5zf8nsf17y76f1kpy14gqgpwyzl8my0w"; </del> }; "x86_64-linux" = { platformStr = "linux64"; projectArch = "x86_64"; <del> sha256 = "1ydjckld89dkpy5zrvk7jjpz70mnlmbm8yinkfpzgcwbkcakk6k7"; </del> }; }; <ins> platforms."aarch64-linux".sha256 = "0m12adzcs6xsmgnqsdc5g0xs6xmjbj560x4d9rnv9fpf1p7jv2fa"; platforms."i686-linux".sha256 = "00cy5kxx8hpifkwhn9qbfch7ng3crx0zb6ypllzip6qms956mama"; platforms."x86_64-linux".sha256 = "1f1hxx4xl0wljyrgj0m3zq47yz2cyqd52qigrkpcvavr1d2sx6m3"; </ins> platformInfo = builtins.getAttr stdenv.targetPlatform.system platforms; in stdenv.mkDerivation rec { pname = "cef-binary"; <del> version = "96.0.18"; gitRevision = "fe551e4"; chromiumVersion = "96.0.4664.110"; </del> <ins> version = "98.1.21"; gitRevision = "9782362"; chromiumVersion = "98.0.4758.102"; </ins> src = fetchurl { url = "https://cef-builds.spotifycdn.com/cef_binary_${version}+g${gitRevision}+chromium-${chromiumVersion}_${platformInfo.platformStr}_minimal.tar.bz2";

Related discussion:
text: I just filed a to update our version of CEF to fix a . The previous version was released on 2019-07-27— that's almost 2 years! For a piece of software that's functionally a web browser, we certainly shouldn't be using an out-of-date version: web browsers have a massive attack surface and it's very important to keep them updated at all times. I don't have the time to work on this right at the moment, but it shouldn't be too difficult. There's a containing metadata for every CEF release. All that should be necessary is to grab the latest stable version for the right platform. While we're at it, we could also consider building for i686 and AArch64. Tagging the maintainer
IDK how it works, but it sounds like a job for the bot ().
Code change:
<ins> # Citrix Workspace {#sec-citrix} The [Citrix Workspace App](https://www.citrix.com/products/workspace-app/) is a remote desktop viewer which provides access to [XenDesktop](https://www.citrix.com/products/xenapp-xendesktop/) installations. ## Basic usage {#sec-citrix-base} The tarball archive needs to be downloaded manually as the license agreements of the vendor for [Citrix Workspace](https://www.citrix.de/downloads/workspace-app/linux/workspace-app-for-linux-latest.html) needs to be accepted first. Then run `nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz`. With the archive available in the store the package can be built and installed with Nix. ## Citrix Selfservice {#sec-citrix-selfservice} The [selfservice](https://support.citrix.com/article/CTX200337) is an application managing Citrix desktops and applications. Please note that this feature only works with at least citrix_workspace_20_06_0 and later versions. In order to set this up, you first have to [download the `.cr` file from the Netscaler Gateway](https://its.uiowa.edu/support/article/102186). After that you can configure the `selfservice` like this: ```ShellSession $ storebrowse -C ~/Downloads/receiverconfig.cr $ selfservice ``` ## Custom certificates {#sec-citrix-custom-certs} The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However several companies using Citrix might require their own corporate certificate. On distros with imperative packaging these certs can be stored easily in [`$ICAROOT`](https://developer-docs.citrix.com/projects/receiver-for-linux-command-reference/en/13.7/), however this directory is a store path in `nixpkgs`. In order to work around this issue the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`: ```nix with import <nixpkgs> { config.allowUnfree = true; }; let extraCerts = [ ./custom-cert-1.pem ./custom-cert-2.pem # ... ]; in citrix_workspace.override { inherit extraCerts; } ``` </ins>

Related discussion:
text: 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.
Hi Opened PR for this.
Code change:
buildGoModule rec { pname = "upterm"; <del> version = "0.10.0"; </del> <ins> version = "0.12.0"; </ins> src = fetchFromGitHub { owner = "owenthereal"; repo = "upterm"; rev = "v${version}"; <del> hash = "sha256-wjbptcGy3wOZPm/11El7Xqz6NrR8G19V9zfU5pKFGuk="; </del> <ins> hash = "sha256-Ljiy23qZTe81qaRTgrpuAdZqdOT8t8+cTqXLpKo5yFc="; </ins> }; <del> vendorHash = null; </del> <ins> vendorHash = "sha256-hXmcgLNzVkU3RC3rj9I+/GlXyxbvPFsoFvVSLJTUHMM="; </ins> subPackages = [ "cmd/upterm" "cmd/uptermd" ];

Related discussion:
text: Package name: upterm Latest released version: 0.12.0 <!-- Search your package here: --- Current version on the unstable channel: 0.10.0 Current version on the stable/release channel: 0.10.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. -- tried
Bumping to 0.12
Seems this need the vendor path now.
Code change:
cmakeConfigureFlags = [ "-DGLM_INSTALL_ENABLE=off" ]; <ins> # fetch newer version of platform.h which correctly supports gcc 7.3 gcc7PlatformPatch = fetchurl { url = "https://raw.githubusercontent.com/g-truc/glm/dd48b56e44d699a022c69155c8672caacafd9e8a/glm/simd/platform.h"; sha256 = "0y91hlbgn5va7ijg5mz823gqkq9hqxl00lwmdwnf8q2g086rplzw"; }; </ins> postPatch = '' substituteInPlace CMakeLists.txt  --replace '"''${CMAKE_CURRENT_BINARY_DIR}/''${GLM_INSTALL_CONFIGDIR}' '"''${GLM_INSTALL_CONFIGDIR}' <ins> cp ${gcc7PlatformPatch} glm/simd/platform.h </ins> ''; postInstall = ''

Related discussion:
text: On nixos-unstable libglvnd (I think) has been failing to build since about a week ago. Build log: Update to the latest nixos-unstable channel Run with nvidia in
Related?
Actually it looks like this PR fixes this issue. Though nix channel is not yet updated.
Confirmed. Adding the following override fixed it for me:
Code change:
--suffix PATH ':' "$out${browser.execdir or "/bin"}"  --set MOZ_APP_LAUNCHER "${browserName}${nameSuffix}"  --set MOZ_SYSTEM_DIR "$out/lib/mozilla"  <ins> --set SNAP_NAME "firefox"  </ins> ${lib.optionalString gdkWayland '' --set GDK_BACKEND "wayland"  ''}${lib.optionalString (browser ? gtk3)

Related discussion:
text: Every new firefox update/rebuild generates its own (new) profile. This is annoying, as we rebuild firefox whenever any of its dependencies changes. See: Start with the profile manager or with a custom profile
Should not it be just one profile per branch – one for stable, one for beta, one for nightly? Updating should not change the branch.
I thought that too, but at least for me it created 4 profiles already - could be, that the FF beta is not smart enough (yet). Anyway, now it's documented, so people hopefully won't get as confused as I've been when/if they reproduce this.
Can repro as well. Unfortunate!
Not explicit above, but the workaround is: you see "this firefox uses a fresh profile"... quit firefox profile manager with an older profile and "use as default profile" as normal until the next update
Related issue: and workaround:
Firefox 67 is now the stable release, when I upgraded unstable this morning I got hit with this issue, I'd guess a lot of other folks will shortly as well. Could the SNAP_NAME workaround be incorporated into the derivation until there is a fix from Mozilla? If there is a better fix out there then maybe that.
Just got made aware of the issues as well. I'd sway te SNAP_NAME workaround is okayish for now. I will try to get a patch made so that we do not need that in the future and have a proper kill-switch for that... Sorry for the troubles. I missed that during testing the latest release :'(
I opened a PR to add the workaround Will do the backport as soon as someone else can confirm that it works as expected.
Looks like the more general solution has been merged into Firefox and will be deployed with 68+. From The dedicated profiles feature is off when MOZLEGACY_PROFILES is set to 1 at environment level, while the downgrade protection is still enabled. Probably should coordinate a change to that environment variable name with the release of 68, though it looks like the SNAP version would work for a while after as well.
Can we set in the latest firefox now?
We could do that but that wouldn't work with former ESR / tor browser and probably a few other things. In the long run that probably makes sense.
Code change:
--suffix PATH ':' "$out${browser.execdir or "/bin"}"  --set MOZ_APP_LAUNCHER "${browserName}${nameSuffix}"  --set MOZ_SYSTEM_DIR "$out/lib/mozilla"  <ins> --set SNAP_NAME "firefox"  </ins> ${lib.optionalString gdkWayland '' --set GDK_BACKEND "wayland"  ''}${lib.optionalString (browser ? gtk3)

Related discussion:
text: I am not sure it is worth the extra code to use the newer (equivalent) option for newer versions and the old one for older versions. There are constantly users that want older firefox versions because of plugins, java, … so we shouldn't just remove them?!
this hasn't popped up in my daily usage for a while now - please comment/reopen if it's still an issue.
Code change:
url = "http://download.enlightenment.org/rel/apps/enlightenment/${name}.tar.xz"; sha256 = "016z1vilhjarpxzn5bwcw696d8b66rklnhkrwzfa5mcxn8gpmvap"; }; <del> buildInputs = [ pkgconfig e19.efl e19.elementary xlibs.libXdmcp xlibs.libxcb xlibs.xcbutilkeysyms xlibs.libXrandr libffi pam alsaLib luajit bzip2 libpthreadstubs gdbm ] ++ stdenv.lib.optionals stdenv.isLinux [ libcap ]; </del> <ins> buildInputs = [ pkgconfig e19.efl e19.elementary xlibs.libXdmcp xlibs.libxcb xlibs.xcbutilkeysyms xlibs.libXrandr libffi pam alsaLib luajit bzip2 libpthreadstubs gdbm ] ++ stdenv.lib.optionals stdenv.isLinux [ libcap ]; </ins> preConfigure = '' export NIX_CFLAGS_COMPILE="-I${e19.efl}/include/eo-1 -I${e19.efl}/include/ecore-imf-1 -I${e19.efl}/include/ethumb-client-1 -I${e19.efl}/include/ethumb-1 $NIX_CFLAGS_COMPILE" export USER_SESSION_DIR=$prefix/lib/systemd/user <ins> substituteInPlace src/modules/xkbswitch/e_mod_parse.c  --replace "/usr/share/X11/xkb/rules/xorg.lst" "${xkeyboard_config}/share/X11/xkb/rules/base.lst" </ins> ''; # this is a hack and without this cpufreq module is not working:

Related discussion:
text: Possible, because X11/xkb/rules/*.lst [0] are somewhere 'hidden' in the /nix/store. [0]
Fixed, just let me do some updating on E19 libraries and I will make a pull request.
Code change:
description = "Decentralized and portable C/C++ package manager"; license = licenses.mit; maintainers = with maintainers; [ HaoZeke ]; <del> platforms = platforms.linux; </del> }; }

Related discussion:
text: Description Attempting to install conan with nix-env on Mac OS X errors out with the following message: To Reproduce Steps to reproduce the behavior: Expected behavior As Mac OS X is a supported platform for conan, it's expected that it would install. Additional context This appears to be due to conan's dependency on the python3-distro package, which only compiles on Linux architectures. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(tclemons): channels(root): nixpkgs:
Code change:
path = [ config.services.postgresql.package ]; }) { <ins> after = [ "network-online.target" ]; </ins> wantedBy = [ "multi-user.target" ]; script = let psql = "${lib.optionalString (!localDB) "PGPASSFILE=${cfg.database.passwordFile}"} ${pkgs.postgresql}/bin/psql ${lib.optionalString (!localDB) "-h ${cfg.database.host} -U ${cfg.database.username} "} ${cfg.database.dbname}";

Related discussion:
text: I tried to install Roundcube with an non-local PostgreSQL. The DB user password should be stored in a password file. I ran into problems with this setup: the password file is used in two locations: the Roundcube the systemd that initializes the roundcube database Unfortunately the neccessary file content differs for these two services: the roundcube the passwordfile should only contain the PASSWORD (even without a trailing newline) expects an entry like "hostname:port:database:username:password" () So one of these two services will fail. Setup Roundcube with remote PostgreSQL server and password file for DB user password. My solution for now would be, to add a line to the roundcube Please run and paste the result. Cheers, Andreas
Your solution sounds reasonable to me, if you replace with something that takes into account escaped . Would you mind opening a PR? Tag me on it, I'll review it. As you can see the remote db feature of the module has probably never been used except by you; if you want this use case to be better maintained consider contributing a nixos test exercising it.
Fixed by
Code change:
<del> { lib, stdenv, fetchFromGitHub } : </del> <ins> { lib , stdenv , fetchFromGitHub }: </ins> stdenv.mkDerivation rec { pname = "proxychains"; <del> version = "4.2.0"; </del> <ins> version = "4.4.0"; </ins> src = fetchFromGitHub { owner = "haad"; <del> repo = "proxychains"; </del> <ins> repo = pname; </ins> rev = "${pname}-${version}"; <del> sha256 = "015skh3z1jmm8kxbm3nkqv1w56kcvabdmcbmpwzywxr4xnh3x3pc"; </del> <ins> sha256 = "083xdg6fsn8c2ns93lvy794rixxq8va6jdf99w1z0xi4j7f1nyjw"; </ins> }; postPatch = '' <del> # Temporary work-around; most likely fixed by next upstream release sed -i Makefile -e '/-lpthread/a LDFLAGS+=-ldl' </del> <ins> # Suppress compiler warning. Remove it when upstream fix arrives substituteInPlace Makefile --replace "-Werror" "-Werror -Wno-stringop-truncation" </ins> ''; postInstall = '' cp src/proxychains.conf $out/etc ''; <del> meta = { </del> <ins> meta = with lib; { </ins> description = "Proxifier for SOCKS proxies"; homepage = "http://proxychains.sourceforge.net"; <del> license = lib.licenses.gpl2Plus; platforms = lib.platforms.linux; </del> <ins> license = licenses.gpl2Plus; maintainers = with maintainers; [ fab ]; platforms = platforms.linux; </ins> }; }

Related discussion:
text: Describe the bug Failed to build . To Reproduce in -rebuild switch Expected behavior Build successful. Screenshots  Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
New warnings/error are introduced with new GCC releases.
could you please give a try?
Yes, it works.
Code change:
{ lib <del> , buildPythonPackage </del> <ins> , stdenv , toPythonModule , fetchFromGitHub , cmake , boost </ins> , eigen <del> , nlopt </del> , ipopt <del> , boost </del> <ins> , nlopt </ins> , pagmo2 <del> , numpy </del> <ins> , python </ins> , cloudpickle , ipyparallel , numba <del> , python </del> <ins> , numpy , pybind11 </ins> }: <del> let propagatedBuildInputs = [ numpy cloudpickle ipyparallel numba ]; pagmo2WithPython = pagmo2.overrideAttrs (oldAttrs: { cmakeFlags = oldAttrs.cmakeFlags ++ [ "-DPAGMO_BUILD_PYGMO=yes" "-DPAGMO_BUILD_PAGMO=no" "-DPagmo_DIR=${pagmo2}" ]; buildInputs = [ eigen nlopt ipopt boost pagmo2 ] ++ propagatedBuildInputs; postInstall = '' mv wheel $out ''; }); in buildPythonPackage { </del> <ins> toPythonModule (stdenv.mkDerivation rec { </ins> pname = "pygmo"; <del> version = pagmo2WithPython.version; inherit propagatedBuildInputs; </del> <ins> version = "2.18.0"; </ins> <del> src = pagmo2WithPython; preBuild = '' mv ${python.sitePackages}/pygmo wheel cd wheel ''; </del> <ins> src = fetchFromGitHub { owner = "esa"; repo = "pygmo2"; rev = "v${version}"; sha256 = "sha256-he7gxRRJd6bBrD0Z0i+CQTr5JH4P3Im/beNGO+HfmNM="; }; </ins> <del> # dont do tests doCheck = false; </del> <ins> cmakeFlags = [ "-DPYGMO_INSTALL_PATH=${placeholder "out"}/lib/${python.libPrefix}/site-packages" ]; nativeBuildInputs = [ cmake ]; propagatedBuildInputs = [ cloudpickle ipyparallel numba numpy python ]; buildInputs = [ boost eigen ipopt nlopt pagmo2 pybind11 ]; doCheck = true; </ins> meta = with lib; { description = "Parallel optimisation for Python"; <del> homepage = "https://esa.github.io/pagmo2/"; </del> <ins> homepage = "https://github.com/esa/pygmo2"; </ins> license = licenses.gpl3Plus; maintainers = [ maintainers.costrouc ]; }; <del> } </del> <ins> }) </ins>

Related discussion:
text: A clear and concise description of what the bug is. The package doesn't include a folder. I am looking for a version of which includes the executable. Are we building the package incorrectly such that it doesn't include a binary? Any and all help/advice is much appreciated :bow: Steps to reproduce the behavior: output - notice there is no folder A clear and concise description of what you expected to happen. I want the executable. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- might know something about this? :man_shrugging:
was the binary there before On a quick note: I have never used , so I am not familiar with the package. It seems that the package also needs an update:
It appears that the binary requires AMPL, a commercial package, which is not packaged in nixpkgs. See: https://coin-
ah, I understand. Thank you.
Code change:
stdenv.mkDerivation rec { pname = "budgie-desktop"; <del> version = "10.7.1"; </del> <ins> version = "10.7.2"; </ins> src = fetchFromGitHub { owner = "BuddiesOfBudgie"; repo = pname; rev = "v${version}"; fetchSubmodules = true; <del> sha256 = "sha256-ww65J9plixbxFza6xCfaz1WYtT9giKkLVH1XYxH41+0="; </del> <ins> hash = "sha256-fd3B2DMZxCI4Gb9mwdACjIPydKghXx8IkhFpMS/Clps="; </ins> }; patches = [

Related discussion:
text: When typing something here: <img src="https://user-" width=50%The desktop crashes and you have to re-login (well it's Chinese in the screenshot but I hope you get the idea) <img src="https://user-" width=50%Steps to reproduce the behavior: budgie menu something crash No crash. See above. I don't see this issue before the GNOME 44 update. Probably another issue but I haven't go deep yet. I am on right now, it's nixos-unstable with pull request picked.
Backtrace points to <details</detailsLooks like there are changes on that touches after 10.7.1, I am testing that right now.
I gave the latest HEAD (i.e. ) a try and cannot reproduce the issue so probably some of the commits fixes the issue. I wonder if this can be reproduce by others and if some fixes can be backported before 23.05
Ohhh goooooood and now I am reading , let me make some noise there Edit:
And now I am on , which has glib 2.74 ( has 2.76). This is going to be weird because with G_SLICE=always-malloc I also cannot reproduce the crash (budgie-desktop 10.7.1), so probably not related to the slice allocator. Edit: and it's vala 0.56.4 on (no crash) and 0.56.6 on (crash)
Okay I guess I can basically confirm it's caused by vala update because I am now on and cannnot reproduce the crash, wow it's first time I know valac can really cause issues :seenoevil: Bisect is too painful for my slow laptop :upsidedownface:
Could you try compiling and running this Vala code on the broken version to see if it also crashes? It should do the same thing as the crashing Budgie code, just without crashing your desktop. If this ends up being a Vala issue, we need a minimal reproduction program to send.