lassulus changed the topic of #nixos-de to: Willkommen im deutschen NixOS Channel.
<lassulus> palo: macht es sinn die ganzen nix-build options einzeln zu wrappen?
palo1 has joined #nixos-de
palo has quit [Ping timeout: 246 seconds]
palo1 is now known as palo
<palo> lassulus: denke nicht. Aber mir ist auf die schnelle keine generische lösung eingefallen. Die meisten nix-build optionen von nix-build machen ja keinen sinn zu übergeben
<palo> :D meine schreib künste wieder :D
<le_jonge> hat jemand erfahrungen mit cross compilation von haskell code fuer raspberry? ich hab mir zw3rks artikel durchgelesen und habe nun den eindruck, dass ich nicht komplett ohne ARM hardware haskell libs und apps fuer raspberry crosscompilen kann wegen template haskell
<le_jonge> und bei meinen kompilierungsversuchen gehen auch genau die template haskell pakete leider nicht
<le_jonge> oder hat das jemand hinbekommen? kann mir vorstellen dass man ja nen qemu mit arm virtualisierung und dann darauf diesem iserv prozess irgendwie arbeiten koennte.
<lassulus> war das nich das was palo bei nixos-generators gemacht hat? Mit dem aarch64-sdimage
<le_jonge> keine ahnung. ich habe nicht mitverfolgt was und wieso palo gemacht hat
<le_jonge> langfristig will ich in unserem projekt in der firma unsere in haskell implementierten services auf nem raspberry pi laufen haben koennen und entsprechende sd karten images aus dem hydra rausfallen haben
<lassulus> Na versuchs mal mit nixos-generators, da hat palo heute was für commitet
<le_jonge> so wie ich das verstanden habe, baut nixos-generators mir doch images von nix system config expressions, oder?
<lassulus> Jo, wollltest ja nen sd-image?
<le_jonge> wenn aber meine haskell app nicht crosscompiled wegen template haskell zeug... ich gehe nicht davon aus dass nixos-generators dieses teilproblem irgendwie loest.
<le_jonge> wenn ich das ueberwunden habe, dann ist nixos-generators wohl das richtige um meine app in ner kompletten systemconfig eingerichtet auf ne sd karte zu kriegen
<palo> le_jonge: jo da hab ich heute was commitet
<palo> le_jonge: wenn haskell nicht unter raspberry pi compiliert, dann hilft dir nixos-generators nicht. Aber wenn du deinen haskell kram auf nem raspberry pi compiliert bekommst, sollte nixos-generators auch funktionieren.
<le_jonge> palo: ja genau das ist mein plan.
<le_jonge> https://medium.com/@zw3rk/cross-compiling-template-haskell-7e38c00c2914 das hier ist halt das was mir kopfschmerzen bereitet
<palo> le_jonge: ich bin kein expere, aber das "cross-compiling" mit das nixos-generators da macht, ist glaub ich eher ne architektur simulation.
<palo> Ich würde es einfach mal ausprobieren.
<palo> sollteste in ein paar minuten wissen.
<palo> Ich nutze das um kernel zu kompilieren (weil ich sie patche) und das dauert echt lange.
<palo> aber nen haskell test-program mit cabal2nix zu packagen und eine kleine configuration.nix zu basteln und testen sollte nicht lange dauern
<le_jonge> ach so... d.h. da laufen gar keine cross compilers drin?
<le_jonge> sondern alles qemu
<palo> boot.binfmtMiscRegistrations < das ist es womit ich das mache. (muss gestehn ich weis nicht was genau dadurch passiert, aber es macht irgendwelche kernel fummelein, deswegen denke ich es ist mehr virtualisierung als `ghc --cross-compile-for=armv6` )
<le_jonge> nice, das muss ich dann wirklich mal probieren.
<le_jonge> ich verstehe nicht ganz was die ganzen dinger da sind mit den magicOrExtension zeug und so. was macht das alles?
<le_jonge> bzw. wofuer wird das gebraucht
<palo> das kann ich dir nicht genau sagen
<le_jonge> aus welchen bundeslaendern kommen hier eigentlich im channel die meisten so?
<le_jonge> wuerde gerne mal mehr nixer persoenlich kennenlernen. vielleicht dieses jahr aufm ccc oder so ist bestimmt ne gute gelegenheit.
<lassulus> aufm camp sollten wir vertreten sein, ich bin aus berlin
<le_jonge> abgesehen davon dass ich auf der arbeit paar angestellte mit nix infiziert habe, kenne ich wirklich keine anderen nix user. schade manchmal!
<lassulus> so fing das bei uns auch an :D aber mittlerweile sind wir immer mehr am wachsen
<palo> Ich bin gerade in Essen
<le_jonge> wenn "tup" nicht so schlecht im nix-environment laufen wuerde, dann koennte ich bestimmt noch mehr kollegen davon ueberzeugen. wir haben unseren eigenen hypervisor gebaut und verkaufen den, und das ist nen schoenes c++ projekt mit komplizierten dependencies (perfekt fuer nix eigentlich), aber leider ist tup das build system das die kollegen ausgesucht haben.
<lassulus> tup kenn ich tatsächlich nicht, aber was ist das problem mit nix damit?
<le_jonge> tup will FUSE benutzen und dazu brauchts das suid bit und das haben sie beim nix paket deaktiviert
<le_jonge> das versucht halt dependencies von allen dateien mitzukriegen indem es watcht welche dateien der compiler so oeffnet.
<lassulus> ah, naja unter nixos kann man das halt mit security.wrappers fixen, aber mit nur nix wird das härter
<le_jonge> man kann mit `tup generate` ein bashscript generieren das den buildprozess sequentiell durchbaut, aber das laueft dann halt nicht parallel.
<lassulus> wie erkennt tup was für buildsteps es gibt?
<le_jonge> hab nen hydra job das den mikrokern, den hypervisor und so weiter baut, und dann noch bootbare usb sticks daraus generiert und testet und alles moegliche, aber schoen waers halt wenn das alles auf hydra _und_ aufm developer schreibtisch laeuft.
<le_jonge> das weiss ich nicht, wie tup das erkennt.
<le_jonge> man kann es auch ohne fuse support laufen lassen, aber dann muss man irgendwie die read usw. syscalls per LD preload ueberladen und so weiter und so fort und wesentlich dokumentiert ist das auch nicht.
<palo> komisches build tool
<le_jonge> tup ist schon ein ziemlich cooles teil wenn man noch nie von nix gehoert hat.
<palo> hab das gefühl gewissen textpassagen hier schonmal gelesen zu haben.
<palo> :D
<le_jonge> :D
<palo> bin nicht so der fan von "schlauen" build-tools. Hab damit tatsächlich immer probleme gehabt. Maven ist das einzige das da ein wenig rausfällt, weil es eine horde an maintainern und so hat. Aber alles was ich so kennen lernen musst : waf, gradle, scons, sbt, ... waren immer nur mehr arbeit für ganz simple sachen, habe nie ein feature gebraucht von dem was da auf den websites immer stand.
<palo> zum glück kommen neu sprachen immer mit nem build tool das ordentlich funktioniert. rust und go haben da zum beispiel einen top job gemacht
<palo> le_jonge: das hilft dir natürlich nicht :D
<le_jonge> ja, aber du hast schon recht. so tools wie scons, tup usw. schmeissen alle environment vars weg und versuchen reproduzierbare environments selbst herzustellen - fuer arme.
<le_jonge> dass man mit nix das environment so anpassen kann dass alles "einfach geht" und man dann z.B. nen anderen compiler ins env schieben kann oder andere libs, ist total die coole sache.
<le_jonge> das geht so mit scons und tup leider halt nicht bzw. die arbeiten dagegen
<le_jonge> ich hab mal das hier als demovehikel gebaut um meinen kollegen zu zeigen was nix so kann: https://github.com/tfc/nix_cmake_example/
<le_jonge> fanden auch alle toll und erstaunlich - aber tup.
<palo> Jo, aber wenn du sagst dein CI baut das für dich, ist parallesierbarkeit wichtig?
<le_jonge> ich liebe das wie man die nix expression ueberladen kann und am ende baut das mit sanitizern usw usw
<le_jonge> also fuer die CI ist parallelisierbarkeit nicht wichtig.
<palo> Und lokal kannst du ja mit binary packages in nix arbeiten.
<le_jonge> aber wenn keiner nix auf seinem laptop bei der arbeit benutzt --> dann pflegt keiner die nix expressions --> dann ist halt kaputt. in unserer gitlab CI benutzen alle docker und am schreibtisch auch und das finden alle ok so.
<palo> Einfach das resultat von tup in nen localen cache hochladen und dann in nem myhypervisor-bin package nutzen
<palo> Ah ok.
<le_jonge> ich hab nen repo gebaut das das ganze projekt in ner privaten hydra instanz baut und fremd referenziert usw.
<palo> zu dem thema haben auf der eloop ein paar sachen gesagt, lassulus wo sind denn die "how to sneak nixos in your workenvironment" vorträge.
<le_jonge> und das baut dann in lauter buildkonfigurationen die cool sind usw. usw. wie so nen demovehikel, aber ich muss die nix exprs halt pflegen sonst veralten sie sofort.
<palo> macht nicht immer sinn nix auf der arbeit auszurollen.
<le_jonge> ja, das stimmt, aber bei uns wuerde es extrem viel sinn machen.
<palo> ist sogar eher kontra produktiv, wenn es eine negative erfahrung wird
<le_jonge> das stimmt natuerlich.
<le_jonge> also ich sneake nix halt schritt fuer schritt bei uns rein und es wird auch immer mehr. und bringt tollen business value dabei. aber ich glaub das hypervisor produkt wird fuer immer nix-frei bleiben (was an sich ja auch ok ist)
<palo> joah, muss aber nicht sein, wenn ein sehr grosse teil der infra schon nix is dann kannste die kollegen deutlich einfacher dazu bringen denke ich, dauert aber halt :D
<le_jonge> ja, richtig
<le_jonge> letztens hat eine kollegin fuer so nen komplexes benchmark-setup die entsprechenden scripts und alles (viel python foo und services die an sein muessen und komplex konfiguriert sind mit spezialhardware usw.) in nix expressions gebaut und deployt das mit nix ops. das hat mich erstaunt - sie hat noch nie von nix gehoert bevor ich ihr empfohlen habe das zu probieren
<palo> lassulus, tv: hab jetzt mal den cache ausprobiert, aber hab das mit dem signieren der packages noch nicht so richtig verstanden, bzw hinbekommen. Das sieht so aus :
<palo> Recher A ist der Raspberry, Rechner B hält den cache, Rechner C baut das Packet und schiebt es nach Rechner B. Und Rechner A will das jetzt natürlich nicht ziehen (denke mal das ihm die signatur nicht zusagt)
lassulus has quit [Ping timeout: 246 seconds]