| 15 Jan 2025 |
 Benedikt Ritter (britter) | SO! Ich werd jetzt auch nixpkgs Maintainer 😉 https://github.com/NixOS/nixpkgs/pull/374095 | 16:06:59 |
 🦎 Valentin 💛🤍💜🖤 (any pronouns) | ich schaffs heute doch nicht, aber dann beim nächsten Mal | 16:36:21 |
 matthias | Wir sind unterwegs | 16:36:55 |
 Leonard Cohnen | https://www.lieferando.de/speisekarte/el-charro-negro-cantina | 18:11:52 |
 Sebastian (he/him) | In reply to@3u13r:matrix.org
https://www.lieferando.de/speisekarte/el-charro-negro-cantina Birria Burrito pozole vegano
| 18:17:51 |
| Leonard Cohnen | Pollo Asada Burrito | 18:19:31 |
| Leonard Cohnen | leonard.cohnen@gmx.de | 19:48:20 |
 Haris | Learning rund um Paket-Hashes: Ich habe für ein Python-basiertes Paket (ansible-core) einen SHA256-Hash "ein-nix-en" müssen. Das geht einfacher als gedacht: nix hash convert sha256:regular_sha256_hash_here | 21:19:06 |
| Haris | Lustig, dass Fluffychat das von Unterstrichen umzingelte "sha256" kursiv darstellt, obwohl es als Inline Code eingetragen wurde | 21:20:23 |
| 16 Jan 2025 |
| Sebastian (he/him) | Hat jemand hier schonmal mit gomod2nix gearbeitet? Bei mir failed der build einer dependency, aber ich kriege es nicht hin mir logs des failenden builders anzuzeigen.
Ich habe gesetzt:
NIX_DEBUG=7 in gomod2nix.buildGoApplication
--print-build-logs --show-trace -L in der command line
build output:
>: nix build --print-build-logs --show-trace -L
error: builder for '/nix/store/yvkjpwnzvc5i6s37dlymyqp5kqjq8zfk-0011_v0.0.0-20231207184443-2918624a9714.drv' failed with exit code 1
error: 1 dependencies of derivation '/nix/store/n75v8lfixn4576hy6bidf10mgfiwrald-vendor-env.drv' failed to build
error: 1 dependencies of derivation '/nix/store/85fpcb4m77g3069y2qfvd3xmbas3ppqr-myapp-0.1.drv' failed to build
| 14:43:11 |
| Sebastian (he/him) | Ach ja, nix log '/nix/store/yvkjpwnzvc5i6s37dlymyqp5kqjq8zfk-0011_v0.0.0-20231207184443-2918624a9714.drv' gibt mir auch leeren output raus | 14:45:30 |
 Paul Meyer (katexochen) | Ist gomod2nix nicht brocken ab go1.23? Habe da letztens was gefixed, das ist aber noch nicht in unstable. | 15:25:20 |
| Paul Meyer (katexochen) | Das erklärt aber nicht die fehlenden logs. | 15:27:47 |
| Sebastian (he/him) | Wenn ich mit buildGoModule aus nixpkgs baue sind logs auf jeden Fall da wo sie sein sollen. | 15:29:58 |
| Sebastian (he/him) | In der go.mod steht auch go 1.21, aber ich weiß nicht ob das einen Unterschied macht wenn ich ein go 1.24 zum bauen nehme. | 15:30:49 |
| 17 Jan 2025 |
| Paul Meyer (katexochen) | Das go 1.21 directive in go.mod ist nicht die toolchain, mit der du baust, sondern nur das minimal language feature set, dass du requirest. Du baust mit der toolchain, die in nixpkgs gepackaged ist, und das ist 1.23 | 08:02:23 |
| Paul Meyer (katexochen) | See https://go.dev/ref/mod#go-mod-file-go | 08:03:02 |
|  d_k set a profile picture. | 22:13:19 |
| 23 Jan 2025 |
|  schromp set a profile picture. | 11:18:25 |
| 27 Jan 2025 |
 bit | Hat sich von euch jemand schonmal mit attic beschäftigt? Der binary cache unterstützt private caches, ich finde aber keine Möglichkeit diese in einer nixos config einzutragen (speziell die Angabe des JWT zur Autorisierung des clients). Ich habe die Befürchtung, dass das nicht möglich ist, finde aber keine Doku/Info dazu | 21:43:02 |
 aaron | Ich habe mir mal vor einiger Zeit diesen Link abgespeichert, in dem beschrieben wird, wie man einen attic Server aufsetzt. Habe das bisher aber nicht ungesetzt. Eventuell hilft dir das weiter: https://lgug2z.com/articles/deploying-a-cloudflare-r2-backed-nix-binary-cache-attic-on-fly-io/ | 22:19:38 |
| bit | Ja, danke. Die Lösung ist die Datei /etc/nix/netrc | 22:48:17 |
| 29 Jan 2025 |
| matthias | ich hab heute was über python und dependencies gelernt. https://akrabat.com/using-uv-as-your-shebang-line/ für das schnelle script zwischendurch eine sehr coole lösung die ich noch nicht kannte... | 19:22:10 |
| 5 Feb 2025 |
 palo | du kannst dein python skript auch gleich mit dependecies via shebang starten mit hilfe von nix-shell
https://nixos.wiki/wiki/Nix-shell_shebang | 02:02:41 |
| palo | (damn wieder falsches wiki, aber text sollte noch funktionieren) | 02:03:32 |
| Benedikt Ritter (britter) | Moin! Mal ne Frage. Ich arbeite mit ein paar Freunden an einer kleinen App und nun wollen wir sie auf einen Server deployen. Wird vermutlich ne Hetzner Kiste und ich konnte alle überzeugen, dass wir natürlich NixOS als Betriebssystem benutzen müssen.
Aufsetzen werde ich mit nixos-anywhere und dann comin um changes auszurollen. Die App selber wird ne Java Anwendung bauen, die wir als Teil der Server flake packagen und dann als systemd Service starten.
Jetzt die Frage: wie setze ich am besten continuous deployment für die App auf? Also ich möchte nach einem Change auf Main von der App automatisch ein deployment auf den Server auslösen. Das heißt ja, dass ich automatisch die Package Definition updaten muss auf den neusten commit SHA. Und die Änderung muss ich dann automatisch im flake repo committen.
Habe daran gedacht das irgendwie über GH actions zu automatisieren. Vielleicht irgendwie mit diesem nix-Update Script, was auch in nixpks die packages updatet?! Bis für jeden Pointer dankbar!
| 18:17:30 |
| Benedikt Ritter (britter) | Da war ein kleiner Tipp Fehler im ersten Absatz „die App selber wird eine Java Anwendung sein“ | 18:18:24 |
 Moritz Sanft | Ich persönlich würde die App in ihrem eigenen Repository mit einer Flake packagen. Dann kannst du die Flake einfach in deinem Server-Repo konsumieren.
Dann kannst du dir Nix-Update sparen. Wenn du alles in dem Server-Repo packagen willst, kannst du Nix-Update einfach in GH Actions aufrufen. | 18:21:56 |
 CRTified | Genau so würde ich es auch empfehlen. Flakes machen das deutlich einfacher | 18:29:51 |
| Benedikt Ritter (britter) | Okay. Aber dass ist schon mal ein guter Punkt. Aber ich muss im Server Repo ja immernoch die flake Referenz updaten. Bzw nix flake Update ausführen, sobald im app repo ein commit passiert. | 18:35:23 |
