| 15 Mar 2026 |
Lisanna | Tomorrow I think I will go through my merged nix PRs and port any applicable ones to Lix. Nothing too extravagant, just minor things. There are a few unmerged ones that are a bit more interesting, but I'll hold off on them for now in case they end up changing from review feedback. Later this week I'll probably join a Nix team meeting and bug them for reviews. | 23:11:13 |
Lisanna | but feel free to comment on the unmerged ones in case there's anything applicable before I get them accepted and port them to Lix | 23:15:57 |
| 16 Mar 2026 |
| draupnirchanged room power levels. | 10:16:20 |
| draupnirchanged room power levels. | 10:16:31 |
Lisanna | Getting used to gerrit again, I'm working on porting https://github.com/NixOS/nix/pull/15105. That PR has two commits, one for the build hook signals and one for the progress bar shutdown message. Should I open these as different changes? | 13:31:30 |
raitobezarius | Yes, but be aware that Lix codebase is quite different in some areas (notably interruptions wise) from cppNix | 13:56:30 |
| 17 Mar 2026 |
| zoë (she/her) joined the room. | 00:10:50 |
zoë (she/her) | this is probably very dumb but: I'm trying to follow "Getting Started with Gerrit", and since it specifically points out "Now you can just git commit your change. No need to create a separate branch", i committed on main directly, but then the no-commit-on-branch commit hook failed because i tried to commit to main, so... am i missing something? | 03:11:46 |
Lisanna | It's still probably a good idea to separate your changes into their own branches, otherwise you'll have to rebase just to edit changes that happened before you make another, unrelated change | 03:16:34 |
zoë (she/her) | right, that makes sense, i was just a little confused at the docs ^^; | 03:17:23 |
zoë (she/her) | aaaand first CL submitted :D
...it's an 8-bytes diff x) | 03:24:38 |
Lisanna | * | 03:58:07 |
piegames | In reply to @blokyk:matrix.org this is probably very dumb but: I'm trying to follow "Getting Started with Gerrit", and since it specifically points out "Now you can just git commit your change. No need to create a separate branch", i committed on main directly, but then the no-commit-on-branch commit hook failed because i tried to commit to main, so... am i missing something? I think that sentence was about remote branches, but you're right it's confusing | 09:14:57 |
| 16 May 2024 |
| zrsk joined the room. | 13:54:49 |
samrose | In reply to @lunaphied:lunaphied.me I think there were a few CLs on the Gerrit but nothing being actively worked The other thing that I could do if it helps is test things and try to find bugs. I did do some C++ work in the past, but may lack the time to do it justice here at least for about 30 days or so | 15:55:29 |
Qyriad | we are not in any rush 🙂 | 17:20:53 |
samrose | Would it help to also test out the existing Lix code and try to find issues/bugs etc? | 17:23:21 |
Qyriad | absolutely | 17:23:41 |
samrose |
- how do people feel about the existing test suite that comes along with nix source code or Lix?
| 17:23:48 |
Qyriad | it's pitiful | 17:24:10 |
samrose | heh | 17:24:16 |
raitobezarius | expanding it is cool | 17:24:23 |
raitobezarius | writing new tests for builtins which are not tested | 17:24:30 |
raitobezarius | new test behaviors, etc. | 17:24:32 |
Qyriad | we have three flavors of test:
gtest (offer only available in libexpr and libutil) bash script virtual machine
the vast, vast majority of testing is in the "bash script" flavor and it is a mess | 17:25:01 |
samrose | I was just going to ask on the "functional" tests: do we still like using bash there? | 17:25:56 |
samrose | the last time that I worked on a major nix related cli project that used bash, or bats for testing, over time it became rather kind of hard to maintain | 17:26:42 |
samrose | I am not usually a big python fan, but in that project we heard from some in the Rust community that they actually use Python to test CLI and seem to have success there. | 17:27:59 |
Qyriad | no gods please kill bash testing. the problem is that it's kind of really difficult to migrate an entire test suite and be sure that you actually migrated the test suite correctly and won't lose coverage accidentally in the process, which makes any kind of migration a bit nerve wracking | 17:28:36 |
samrose | yes it's a rather large undertaking | 17:28:52 |