| 9 Jan 2025 |
 hexa | room title and icon are gone here 🙈 | 21:02:54 |
 Winter | not here | 21:03:06 |
 Emma [it/its] | still here for me aswell | 21:41:34 |
| hexa | flushed cache and reloaded ,still gone 😄 | 21:41:50 |
| hexa | but #dev:nixos.org as room name is fine ig | 21:41:58 |
| Emma [it/its] | proposal to change the room alias to #nixpkgs:nixos.org :p | 21:42:27 |
| Emma [it/its] | or #nixpkgs-contrib:nixos.org works too i suppose | 21:42:46 |
| hexa | the split is currentls devs vs users | 21:46:49 |
| hexa | * the split is currentls devs vs userss | 21:46:50 |
| hexa | * the split is currentls devs vs users | 21:46:51 |
 adamcstephens | Is the port-to-stable tag new? | 22:52:52 |
| adamcstephens | in what cases should it be used? | 22:53:20 |
 ElvishJerricco | hexa, emily: I don't like the ideas of a submenu for both kernel versions or inlining the menu. I don't want the initial boot loader to look like some big wizard UI where you carefully pick what to boot. It should be like "here's the default, it should work. Here's also some alternatives that may improve common problems". | 23:04:39 |
| ElvishJerricco | like e.g. the hidpi options are under a submenu because dumping a ton of extra boot entries in the toplevel is just a lot and confusing | 23:05:28 |
| ElvishJerricco | * like e.g. the "HiDPI, Quirks, and Accessibility" options are under a submenu because dumping a ton of extra boot entries in the toplevel is just a lot and confusing | 23:06:00 |
| ElvishJerricco | * like e.g. the "HiDPI, Quirks and Accessibility" options are under a submenu because dumping a ton of extra boot entries in the toplevel is just a lot and confusing | 23:06:11 |
| hexa | In reply to @adam:robins.wtf
Is the port-to-stable tag new? has/needs? older | 23:16:13 |
| 10 Jan 2025 |
|  @tomog:matrix.org left the room. | 05:03:40 |
 aloisw | In reply to @hexa:lossy.network
room title and icon are gone here 🙈 your homeserver name is appropriate | 07:27:44 |
 Niklas Korz | Is there a Ruby-specific room? At least I can't find one in the space search | 10:31:15 |
| Niklas Korz | https://wiki.nixos.org/wiki/MatrixRooms also does not list one, so I guess not 😄 | 10:32:14 |
| Niklas Korz | So I'll just ask here (also it's probably more of a stdenv question than a Ruby-specific question):
pkgs/development/ruby-modules/bundled-common/default.nix has special handling for gemset to be of type set instead of string / path, which I'd like to take advantage of to make it easier patching the gemset attribute set from overrideAttrs and passing it to bundlerEnv. This works fine.
Now to allow the override I tried setting gemset as an attribute on the stdenv args and then reference it as finalAttrs.gemset in bundlerEnv. Thid doesn't work as stdenv errors about gemset not being a string. I know I could set gemset as a package parameter instead and use override to override gemset as a whole, but the idea of using finalAttrs and gemset as an attribute set was that I could access prevAttrs.gemset in overrideAttrs. Is there a way to pass along non-string attributes in finalAttrs?
| 10:39:34 |
| Niklas Korz | * So I'll just ask here (also it's probably more of a stdenv question than a Ruby-specific question):
pkgs/development/ruby-modules/bundled-common/default.nix has special handling for gemset to be of type set instead of string / path, which I'd like to take advantage of to make it easier patching the gemset attribute set from overrideAttrs and passing it to bundlerEnv. Setting gemset to an attr set works fine, so this is not the problem.
Now to allow the override I tried setting gemset as an attribute on the stdenv args and then reference it as finalAttrs.gemset in bundlerEnv. Thid doesn't work as stdenv errors about gemset not being a string. I know I could set gemset as a package parameter instead and use override to override gemset as a whole, but the idea of using finalAttrs and gemset as an attribute set was that I could access prevAttrs.gemset in overrideAttrs. Is there a way to pass along non-string attributes in finalAttrs?
| 10:40:16 |
 Gaétan Lepage | Looks like GHA are struggling right now... | 10:50:51 |
| Niklas Korz | ok for my usecase it's not relevant anymore, but would be interesting to know nonetheless 😄 | 11:06:59 |
 @nhp:matrix.org | how would I go about submitting an update to a package (ares) that needs a new dependency (librashader)? I submitted a PR to package librashader, but updating ares depends on that being merged, so should I just wait or is there a way to submit a PR that depends on another PR? | 16:18:23 |
 K900 | You can just put both in one PR | 16:18:56 |
| @nhp:matrix.org | ah, okay - should I just close my existing one or is it better to edit it? | 16:30:18 |
