Mic92 has quit [Quit: Connection closed for inactivity]
palo_ has joined #nixos-de
palo_ has quit [Changing host]
palo_ has joined #nixos-de
palo has quit [Ping timeout: 272 seconds]
Mic92 has joined #nixos-de
Mic92 has quit []
Mic92 has joined #nixos-de
Mic92 has quit [Quit: WeeChat 2.2]
Mic92 has joined #nixos-de
Mic92 has quit [Client Quit]
Mic92 has joined #nixos-de
palo_ is now known as palo
<jonge>
hey leute, diese `makeRPM` funktionen in pkgs/build-support/vm/default.nix - sind die dafuer da um meine nix expressions in rpms zu verwandeln die jemand dann ohne nix verwenden kann? oder verstehe ich den usecase falsch?
<lassulus>
glaub das wird aktuell dazu benutzt, um das rpm release von nix zu bauen, evtl tuts auch mit anderen paketen
<jonge>
was ist gerade der einfachste weg von "ich hab ne funktionierende binary aus ner nix expression meines projekts, die dynamisch linkt" um etwas zu produzieren, das man z.B. auf nem alten centos ausfuehren kann, ohne dort nix zu installieren?
<jonge>
klar kann ich die libraries alle in nen ordner packen und mit patchelf da durch gehen... aber gibts irgendwas das mir das abnimmt?
<Mic92>
jonge: Ich glaube es gab irgendwas, was sich selber entpackt hat zur laufzeit. Moment.
<Mic92>
jonge: hast du Zugriff auf /dev/kvm by chance?
<jonge>
also ich bau hier nen C++ projekt das am ende noch auf centos 6.8 ("viele kunden benutzen das halt") laufen muss. das kann ich nicht beeinflussen. und nun ueberlege ich wie ich das am besten hinkriege... docker kannste knicken, /dev/kvm kannste knicken - und das ding muss direkt mit dem kernel reden (audit interface)
<Mic92>
Aber wenn du rpm installieren kannst, hast vermutlich root
<jonge>
root hab ich.
<jonge>
die haben so nen total krudes build system das richtig doof ist und ich will das alles gerne mit nix machen. kunde sagt "pass auf. wenn du damit ne binary bauen kannst die bei allen kunden laeuft, ist uns das egal. wenn nicht, dann muss es leider das krude alte build system sein."
<Mic92>
da packen wir einfach den nix store in packete rein
<Mic92>
in dem Fall nix
<jonge>
das bedeutet z.B. das rpm paket eroeffnet stur nen /nix/store ordner und klopft alles da rein, aber halt ohne dass man dafuer nix installiert haben muss?
<Mic92>
jonge: so sieht es aus. Evtl. brauchst du dann noch wrapper die von /usr/bin/ auf den nix store zeigen. oder du packst was in /etc/profile.d rein, was geht.
<jonge>
das klingt sehr gut! wenn jemand so krass drauf ist dass er so alte software wie centos 6.8 benutzt, dann wird dem auch der /nix/store ordner egal sein duerfen...
<Mic92>
Vorteil ist, dass du dann so ziemlich unabhängig vom system bist.
<jonge>
danke, das werde ich mal probieren!
<jonge>
koennte auch fuer unsere eigenen produkte von interesse sein...
<jonge>
fpm muss auf dem zielsystem installiert sein?
<jonge>
oder wird das nur auf dem build system gebraucht
<Mic92>
cool wäre wenn fpm einfach nix als source unterstützen würde.
<Mic92>
Obwohl man lieber eine default.nix hat, die einfach fpm called.
<Mic92>
Ansonsten braucht man wieder ein shell script das fpm aufruft.
<jonge>
na klar
<Mic92>
Ich könnte mir noch gut vorstellen dass man sich damit eine Art Module packetieren könnte, die dann sich auf dem Zielsystem in systemd integrieren und auch ihre Konfiguration mit bringen.
<jonge>
hab mir grad die default.nix angesehen. sieht mir so aus als wuerde ich die also an mein projekt anpassen - oder vorher so verallgemeinern dass es mit beliebigen paketen geht, richtig?
<Mic92>
Wenn es verallgemeinert werden würde, wäre das cool. Quasi ein nix2fpm.
<jonge>
fpm scheint mir bereits ein paket in nixpkgs (zumindest unstable) zu sein. war das anders als du das repo da gebaut hast?
<Mic92>
es gab glaube ich eine änderung in dem Fork.
<jonge>
ok... wuerde man sich dann in den nixpkgs ueberladen
<jonge>
ich versuche nur grad den scope einzuschaetzen weil ich das evtl. einem weniger erfahrenen mitarbeiter auftragen wuerde. der angenehme nebeneffekt waere dass er danach mehr ueber nix gelernt hat.
<Mic92>
das wird auch schon in nix-fpm-multiuser getant