<ericson2314>Hi, I have long hoped that the Nix community (from where I hail) and the Guix community might standardize the store layer they still largely have in common <vldn1>what do u mean by standardize the store layer? <ericson2314>but, more abstractly, derivations, store objects referenced by store paths, building, sandboxing etc. <vldn1>you want to have the same system but with two languages? <vldn1>just make a language wrapper for guile or create an nix importer for guix <ericson2314>Everyone has different ideas on how to write down the packages (Guile Scheme, nix lang, flakes, Tweag's Nickle, etc. and that's great! <ericson2314>but I think a will to create standard that is bigger than either community would be very useful <ericson2314>e.g. say one is trying to, at their school or research institution, set up a build farm <ericson2314>it would be nice if guix and nix users can ask for a single build farm they both share <ericson2314>there are a lot of improvements to the store layer implementation I think could happen, especially for the "data center" use case, and I figure it would be nice if both projects could benefit form day 1 <vldn1>they are two different systems <vldn1>they don't devide just in the store implementation <vldn1>i don't know how they should share a build farm.. <vldn1>some sort of substiution server sharing would get problematic with lib dependencies and versions <ericson2314>I few things (e.g. Guix gained support for blake hashing if I am not mistaken?) but I don't think any philosophical differences <ericson2314>it is unlikely they two systems would share any data in common except for source code <ericson2314>(at least so long is Guix is using guile at build time, and Nixpkgs is using bash at build time) <vldn1>they use different package definitions based on their repositorys .. <vldn1>and different packages avaiable <vldn1>+ another package manager + other store definitions = different system <ericson2314>that you can mix together completely unrelated stuff in a nix/guix store has been a feature from day 1 <ericson2314>so different package visions etc. is a complete non issue <ericson2314>if there are incompatabilities in specific formats, etc. if one has derivations or store paths the other cannot parse/validate that could be a problem <ericson2314>but that is completely separate from "different package definitions" <mbakke>anyone else working on core-updates? <sneek>mbakke, davidl says: how is it going with the ganeti-instance-guix pull request? It would be nice to have it merged and an updated guix package on guix master. <vagrantc>ericson2314: but guix keeps a database of files in the store, somehow you'd have to get guix and nix to cooperate on where to store their respective databases <vagrantc>ericson2314: otherwise guix gc will purge all the nix stuff, and presumably the correlary from nix <ericson2314>vagrantc: is this the sqlite database inherited from Nix? <vldn1>ericson are u deep in the nix-store implementation <vagrantc>i'm not sure there's that much to gain, honestly ... you can have two difference stores on two different paths with almost all the stuff in them different <vldn1>guix uses the nix-store from a few years ago with a bit of command line stuff and gc stuff added <vldn1>but it is the same old nix-store in g++ <vagrantc>maybe you'd get the occasional upstream tarball or git repository that matches? <ericson2314>you know how they call IP the "thin waste" of the netowrking stack? <vldn1>we are eager to replace it with a guile replacement <ericson2314>I want standardize this stuff as the equivalent "thin waste" of a broader "guix nix and beyond" world <mbakke>it would be great to join forces for the upcoming GCC 11 and Python 3.10 upgrade <mbakke>currently icecat and ungoogled-chromium are building, but gnome is not <ericson2314>Well sure happy to help out with issues with specific packages, patches on them, etc. too <ericson2314>it has resurfaced after some time incubating on a private branch <ericson2314>I have a few dreams with this thin waste stuff. One is that anyone that is implementing new build system infra and wanting to show off their fancy implemention should want to implement the "store standard" as a way to get nice comparison with other system <ericson2314>Tvix is sort of one one those projects, grown out of frustration with Nix's bad politics <ericson2314>but I would want other projects not even "forks" from the nix or guix communities to sort of treat our core interfaces as "the proving ground" <ericson2314>vidn1 c'mon, the reason I come over here is because I don't want to create a new standard <ericson2314>I want to standardize what we already have in common <ericson2314>if it sweetens the deal, I am happy to help you all rewrite the remaining C++ bits in guile <vldn1>i'm sorry, just reminded my self on this comic <ericson2314>it's exactly to avoid the XKCD pitful that I am doing the hard work of showing up to a new community where no one knows me and making an awkward overture :) <vldn1>i'm a super small fish here maybe someone of the big heads are the right person to talk to you for this project :) <ericson2314>but i figured I should stick my head in IRC first less I make a fool of myself saying somehting silly :) <vldn1>i just got myself into writing some parts in guile for the guix-store last week so i had this github link to the store in my head :) <vldn1>just introduce yourself a bit and write to some of the main contributers i thinks <ericson2314>It is an uphill battle, the sort of layering here I am very keen on I don't get a sense the Guix community cares so much about, from reading blog posts <ericson2314>and the portion of the nix community that is more flakes oriented also seems disinterested <ericson2314>So I can explain the technical merits of what I want, but I am not really sure yet how to pitch it in a way that makes people excited <ericson2314>Sticking with the Ninja example, the dual of new implementations implementing it as a "proving ground" is new higher lever things being able to output it <ericson2314>like CMake outputs ninja, I really wish the Cargos, Yarns, etc. of the world would spit out something both our projects were ready to consume <ericson2314>I am not sure if you all have "lang2guix" tools like we have "lang2nix" ones, but while those can work surprisingly well, they are always doing something the upstream language-specific package managers did not really anticipate <vldn1>the tools are implemented in guix <vldn1>and can even recursively search the dependencies <ericson2314>do you typically commit those and regenerate them periodically? <vldn1>using the nix importer for python code was a nightmare <vldn1>all importers are so flaked around in nix, some are deprecated <ericson2314>or is there way (like our "import from derivation") to generate on the fly? <vldn1>guix has way better implementations of a lot of things, but some things are way worse and a bit slower <vldn1>but guix is missing some man power <ericson2314>yeah so standardizing the parts where we aren't trying to do things differentlyu can help with labor shortage :) <ericson2314>even if there is separate Guile and C++ implementations (good! And hopefully many more!) we could share test suite <pkill9>which things are way worse that youre referring to vldn1 <ericson2314>and daemon protocol (what's yours like? ours is still quite evolved and not too pretty) <ericson2314>e.g. you can run the nix test suite against nix with daemon <ericson2314>and I think it would be wonderful if both project's reference daemons could be used with each client passing the test suite <vldn1>pkill9: guix gc's too much, you have to downloads lots of stuff after gc -d instead of nix gc's that seems to keep the right things for example <vldn1>pkill9: pulling and rebuilding the whole package first before hand a full system upgrade is annoying too <pkill9>what do you mean with the second one? <vldn1>a guix-daemon guile implemention could help to not have the daemon builded before and just use it from guile directly maybe.. would minimize the chicken / egg / pulling problem <vldn1>nix-channel --update vs guix pull @ pkill9 <vldn1>the first one goes in 3 seconds on my pc <vldn1>the second one needs 5 minutes :D <vldn1>because it updates the git repo and rebuilds the whole guix package <pkill9>oh, you mean guix upgrade, i thought you meant reconfiguring the sustem <pkill9>yeh guix pull is annoyingly slow <pkill9>is it fixable though? nix does lazy loading <ericson2314>when you guix pull you get new packages including guix itself? <vldn1>you bootstrap guix on every guix pull <vldn1>pulling the newest commits and bootstrap it <vldn1>no we have caching, not the fastest one but it is there <vldn1>and there should be a more efficient way i think but i'm not too deep into the bootstrap thing sadly <vldn1>maybe instead of building guix locally just downloading a substitute..? xD don't know <vldn1>maybe the guix program is an exception or needs some things to be compiled at runtime don't know <ericson2314>well anyways, I gave 3 basic motivations: new back end implementations, trying to get the upstream projects to help out on the `guix import` front, and trying to generally reuse work / get around personpower shortages <vldn1>maybe decide between reimplement the c++ nix-daemon in guile or a guix import command for nix packages <vldn1>that we could import nix package definitions easily via a guix import nix :D <ericson2314>you could do nix -> scheme, but it wouldn't look like the other importers <ericson2314>or you could just get our derivations but it would be lexx flexible <ericson2314>reimplementing the C++ nix I don't feel like it's intrinsic motivation <ericson2314>like I could always help out, I just am only motivated to if I think it won't lead to further drifting apart at the store layer (i.e. we have a spec we both refer to) <pkill9>vldn1: guix pull alrrqdy downloads subatitutes if theyre available <yewscion>Hello all, does anyone have any news on the status of GWL? I've noticed the site (https://guixwl.org/) has been down (502) for the last week. <nckx>yewscion: That's just a left-over infrastructure issue, that has nothing to do with the status of the project. <nckx>In fact I think it just saw a release, or is about to. One of the two. <yewscion>Copy that, great to hear. Is there somewhere else I might watch for more up-to-date information on GWL? <nckx>And no, I'm not sure what the dealio is between the 2 domains. <nckx>I don't even know what guixwl.org is supposed to be. It points to localhost:5000. Need I say that there is no service (AFAICT) declared for that port? *nckx suspects another screen-based rekado original. <mroh>nckx: does noisetorch work for you? It doesn't start over here. <nckx>I think I had to setcap it first, but it ran fine. <Cairn>Hey, so I have a package that uses `cmake-build-system`, but also requires `extra-cmake-modules`. Do I specify that somehow in as part of the build system or do I just add it as an input? <clarity_>so wait, I can install guix on top of alpine on arm64? <atka>clarity_: how can you install guix on alpine? isn't musl a dealbreaker? <clarity_>they have a glibc mode, but probably doesn't work <atka>I run alpine and guix myself <atka>not together of course, but my go to distros <atka>run well with default kernel? <clarity_>the pinebook pro, I'm not sure, I just set it up today <atka>all I look for in an sbc is if it can run vanilla alpine with vanilla kernel <atka>pinephone is tempting as is the pbp <atka>but can't bring myself to order from them <atka>also, what is so bad about the pinephone pro? early days and lack of support or hardware issues? <yuu[m]>i think we would benefit very much in having greater integration in such a standard. people from nix would try guix and guix people would try nix in a more seamlessly way <yuu[m]>for example, i've got increasingly interested in guix because its emacs ecosystems seems better. so i want to use Guix specifically for that, while still for now maintaining main use on NixOS (although i'm trying to dualboot). <yuu[m]>and i know Guix users also use Nix for greater software availability <yuu[m]><ericson2314> "I am not sure if you all have "..." <- guix has built-in importers for langauges. but they differ with Nix ecosystem in that they try to bootstrap the packages including dependencies for everything; so no downloading binaries for the dependency-tree in fixed output derivations like many 2nix do. <yuu[m]>by bootstrap i mean building from source <yuu[m]>and thus the quantity of importers are probably less than 2nix tools. for some ecosystems like node, probably guix won't see any actual solution for a good time. <rekado>nckx: guixwl.org has a service. That service requires a more recent version of gwl because the latest release has a bug. <yuu[m]><nckx> "yuu: (dependencies %file-system..." <- btw thank you very much, that worked!! i'm also now better understanding how to read/fix those errors <yuu[m]>how much memory does guix system init needs? my vm i'm using 2gib. but i think it's getting oom <abcdw>I pushed a commit updating emacs-geiser-guile inputs one more time, hope it won't break guix pull again!) <yuu[m]>are there mirror susbstitutes? guix.gnu.org's is at 140kib/s đ ***Dynom_ is now known as Guest9872
<rekado>the python-build-system is a bit frustrating to me. There are a number of packages that do twice the amount of work because extensions are compiled in the 'build phase and then *again* in the 'install phase. <rekado>can we avoid this automatically? <rekado>(I donât want to patch every package where this happens) <mbakke>rekado: that should be fixed with the revised build system by PurpleSym <PurpleSym>mbakke: Itâs bit-rotting and probably does not apply to master any more. I donât have much time for Guix right now âšď¸ <vldn>would be nice if the "guix package" cli interface would support the guile --language flag <vldn>or guix the guix client in general, then someone could write manifests and system definition via wisp <rekado>vldn: perhaps itâs still possible with a little Guile snippet at the head of the file <jeko_>I want to create a shell script where I call a `guix shell` command before executing a bunch of other commands. but my script stop its execution at the `guix shell` line⌠<rekado>vldn: you could have a separate adapter manifest that loads your wisp manifest: ((@ (system base compile) compile-and-load) "manifest.w" #:from 'wisp) <jeko_>how can I make it to continue its execution? <rekado>vldn: if it was possible to return early we could do this all in the same file <rekado>(call-with-input-file (current-filename) (lambda (port) (read port) (((@ (system vm loader) load-thunk-from-memory) ((@ (system base compile) read-and-compile) port #:from 'wisp))))) <vldn>is it possible in a system definition? like to import guile-wisp to get around the "no such language wisp" error? <nckx> jeko_: My guess is you're just entering the shell without giving it any commands to execute, so it waits for them forever. Share the script. <mrvdb>Is someone working on rust for the powerpc64le platform? rustm (bootstrapping compiler) is apparently not supported and everything upwards for rust depends on it. (and many things seem to depend on rust) ***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!clararuss@*
***litharge sets mode: -o litharge
***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!*clararuss@*
***clararussell[m] was kicked by litharge (You are banned from this channel (by nckx))
***litharge sets mode: -o litharge
***ChanServ sets mode: +o litharge
***litharge sets mode: -bo *!clararuss@* litharge
<nckx>ericson2314: Our list? Like others, I see only drawbacks to sharing a standardised âstore layerâ with anyone, but very interested in reading the discussion! <ericson2314>nckx: what drawbacks? I have a big long email being drafted but I ma not sure that is a good way to convince anyone of anything :/ <ericson2314>I am worried that there are those of us that are obessed with layering and modularity, and there are those of us that don't really care at all, and converting someone from either camp to the other is very hard <nckx>I'll still read it with interest, even if I'm not convinced :) <nckx>There are plenty of people who care when given good arguments. <nckx>It's about substitute servers, right? <nckx>Ah, sorry, have to go o/ <ericson2314>substituting sure that's a benefit too, but yes that is far less interesting to me. <ericson2314>good negotiation/pitching means one has to know what the other side cares about <ericson2314>I know some technical details about Guix (and of course the stuff that is in common) <ericson2314>but I have little idea what the Guix community cares about <ericson2314>so I am just throwing shit against a wall right now, hoping something sticks <drakonis>the real question, what's in for the guix folks to do this? <drakonis>having the daemon remain a piece of poorly understood c++ hasnt helped much <drakonis>can i run the draft through the hpc channel? <drakonis>it has a greater chunk of active contributors and less traffic, so it is less likely to get lost in the logs <drakonis>also we could probably work on this with a goblins implementation <drakonis>given that syndicate's author hangs out on spritely's irc <ericson2314>the tittle sounded good, but then the body of that one got really...unexpected to me from a quick glance <ericson2314>we need something which isn't an arecane ad-hoc binary protocol <nckx>Arguments I can see: we don't have to maintain (which is to say, occassionaly notice and continue to ignore) the C++ daemon, the daemon core project will do this. Bugs & security issues will get found & fixed. We'd be able to describe ideas in English and maybe even see them implemented. <drakonis>right now, the main thing i would argue that has to change is how the daemon stores metadata <ericson2314>nckx: yes there is one version where I help you all rewrite deamon in Scheme so no mroe C++ <nckx>By the way, if this isn't called the âDaemon Coreâ project, don't bother. <ericson2314>there is another version where we just share one daemon/store impl in a 3rd repo <drakonis>frankly, i'd rather have the daemon in scheme due to goblins <ericson2314>drakonis: I think HPC is a huge benefit so that sounds good <drakonis>sharing the implementation in a third repository would also be an interesting thing, provided it doesn't become a noose for us <nckx>Oh, right: there is a tiny chance this community might be biased towards Scheme. <ericson2314>My work has clients of data center Nix and...it's a goddamn mes <nckx>drakonis: My main counterworry, I think. <drakonis>basically, i've been looking into goblins because it would let me build a daemon that is capable of being distributed <ericson2314>I have done some work splitting the scheduler parts froim the building parts <ericson2314>but trying to push this in the Nix community is really hard <ericson2314>I am 2nd/3rd most prolific contributor to C++ Nix, I am still begging to get my PRs reviewed etc. <drakonis>frankly, what i want out of a daemon rewrite is to free it from the shackles of the current execution model <nckx>ericson2314: Not a point where Guix competes, though. Until you get commit access it's the same here. <drakonis>it is a lot easier to get things merged, no? <ericson2314>Our governance situation is finally starting to improve, but tbh my "ulterior motive" if there is one, is I think we need multiple interoperable implementations to have more effective community competition with less swithcing costs <ericson2314>there is Nix and Guix, Tvix which is also in response to Nix governance issues, etc. etc. <nckx>I can't compare with Nix. I just know I wouldn't give Guix 5 stars in any context. <ericson2314>I want "choose how you want to write packages" and "chose how you want to sysadmin your institutional-scale build farm" to be orthogonal choices until this stuff is sorted out <drakonis>i do not appreciate that the current nix daemon execution model is a noose for running arbitrary scheme pipelines <drakonis>last i checked, nix still stores only the node graph <drakonis>this has caused a bunch of impedance mismatches with guix features because the format does not allow storing more information <drakonis>so if i want to make grafts better, i'd have to throw out most of the work done <ericson2314>yeah it would be pretty interesting to go more "harvard arch" and *only* put drvs in the db, and entirely in there <drakonis>i want to get rid of sqlite and use a sexps object format on disk <drakonis>then store a schema that gets loaded by the daemon on runtime <nckx>Another fair warning: âcommunity competitionâ is pretty far from the Guix model of one coherently managed project, and the culture around here in general. Selling it might not have the effect you intend. <drakonis>if necessary, build another database persistence layer on top of it for cuirass/hydra <nckx>I know what you mean, but it's worth pointing out nonetheless. <drakonis>i have this nagging feeling that i'd rather throw out most of the work done on guix's internals and start over <drakonis>and none of this would ever be accepted by the nix community because they have a very particular view of how to do things <drakonis>ericson2314: but would you really do it in scheme? <ericson2314>nckx: right I see I am sounding like some neoliberal with all this competition and "switching costs" bussiness <ericson2314>and guix is more about the warm embrace, monorepo of boundless integration, etc. <drakonis>to be fair, we've had working multiple repos for years <drakonis>well, the mainline repository has the packages and the source for guix in the same place <ericson2314>Yeah that is BSD or Google brain nonsense to me, but to each their own :) <drakonis>but using code from other repos is fairly trivial <ericson2314>Re the pingged message, I like lisp but I need types for my own work. But I will pitch in nonetheless helping you all rewrite the C++ in Guile Scheme if that is what it takes <drakonis>because you gotta have a nice out of the box experience <ericson2314>My specialty is working on code I didn't write, I'll make do <ericson2314>btw did you two start looking at the doc thing I shred? <nckx>ericson2314: <neoliberal> I didn't mean to imply *that* much, sorry if that's how it sounded. <ericson2314>nckx: that is how it sounded to *me*, writing it! :) <nckx>ericson2314: Also, I was deliberately avoiding âmonorepoâ because it's not quite what I meant. If you've ever tried to build Android⌠And yes, we have channels, but it is very much the Linux kernel module model (for lack of a better example on short notice): we get carried away on Refactoring Friday, you downstreams better be ready to follow. <nckx>Also every day is Refactoring Friday. <nckx>I'm not as familiar with Nix flakes/modules/whatever as I wish I were but I believe the model to be very different. <ericson2314>I refactor the hell out of everything too yes, but I don't think layering is the enemy of that <nckx>No, it's often a friend. <ericson2314>though I certainly am sympathetic that it looks like itis <nckx>We just don't have much of it ATM. <nckx>I've heard that before, which makes me *even more* curious :) <drakonis>nckx: it has been a point of contention for years <drakonis>the people that have been around for long think it is a worse solution than what exists because it enforces a specific model <ericson2314>I thought Nix was good, but then we get this thing where all this functinoality is dumped together with no separation of concerns like it is a good thing <drakonis>flakes are great in a nix world without it <drakonis>however, nix also has a problem where there's a hundred ways to do the same thing and they're all the same but with different gotchas <ericson2314>Yeah we do need more uniform practices, but we also need flexiblity to refine those practices as new needs arise <nckx>Point taken. I'll make a note not to mention âNix flakesâ as an arbitrary example anymore. <ericson2314>I have done "refactor friday" on Nixpkgs for cross compilation for example <drakonis>nix flakes are liked by newer folks though <drakonis>because it fixes one of the biggest problems with nix <ericson2314>I want to say "look, you cna have flakes, jsut don't make it obligatory" <drakonis>you have to go through nixpkgs for pretty much anything <ericson2314>you can make tool where Nix flakes is built in at ever level <ericson2314>but it should be able to use a nix lang evaluator that doesnt' know about flakes (no longer exists) and a daemon that that has none of that stuff linked in (no longer exists) <nckx>I didn't realise the daemon was involved. <nckx>I am definitely not going to use them as an example of anything because they are obviously nuttier than I thought. <ericson2314>I prefer the iron guarantee of it not being linked in at all <drakonis>the community is very unconcerned with the needs of the flesh <ericson2314>Flakes themselvse are not even "obviously nutty" I would say, in fairness, but the methodolgy behind them is deeply suspect <drakonis>the whole nix model is wrapping everything in closures <drakonis>even at the cost of making it a clean abstraction <ericson2314>there is no smoking gun, but just a general unease / nausia the harder one looks <drakonis>nix-env and nix profile barely work as it is <drakonis>since you have to wrap almost everything <drakonis>they already patch everything, they also have to wrap everything to go with it <nckx>I shouldn't have said âobviously nuttyâ, it was not what I meant. <nckx>Just that they clearly carry connotations that stimulate discourse away from the rather tame (and not that interesting) point I was making :) <sneek>Welcome back gabber, you have 1 message! <sneek>gabber, mbakke says: you can get the log file with 'guix build --log-file PACKAGE' <nckx>It's OK to be that person. Although the Guix definition of a speedy merge is a patch merged within a few days. <linj[m]>hi guix, can you hear me on the irc side? <silicius[m]>I wish it was easier to use packages I defined in my local guix copy before they get accepted. For now I can copy them to my local channel but it's kinda meh <drakonis>silicius[m]: you can evaluate and install a package definition that's in a file, no? <drakonis>ericson2314: i'm surprised to see you're here though <drakonis>is it some kind of "stare longingly at guix and wish nix was half as nice" thing? <silicius[m]>drakonis: how does it help me if the package is not the only one in the file? <ericson2314>I have my own galaxy brained ideas for writing packages (logic programming like stuff) <drakonis>silicius[m]: you can call the package by its name at the end of the file and it'll evaluate to it <drakonis>if i get around to writing a fresh daemon, i'd be bound to use it to write a dependency solver with it <silicius[m]>drakonis: installing it with ./pre-inst-env actually worked. I always assumed it wouldn't <drakonis>did i accidentally steal a nix contributor? <drakonis>but you do that if you're working with the main repository <silicius[m]>Yeah I am. I just thought thar ./pre-inst-env separates the compiled guix from the system guix more <ericson2314>drakonis: I will probably "retire" as an hnix-store contributor <drakonis>speaking of hnix, has it ever yielded any returns besides more work? <ericson2314>but I think starting with the language part was a mistake <ericson2314>the lowest hanging fruit to me is unquestionably the store layer <drakonis>should've made a nix in haskell without the nix lang <drakonis>how do the nix folks feel about interop beyond a "performative" manner? <gabber>nckx: fair enough :) i'll get back here if it isn't merged within a week or so <drakonis>i've been on matrix and talked about a nix rewrite in another language and i've been asked about whether it would be compatible with the nix daeomn <rekado>silicius[m]: there are several ways to extend Guix. Channels are the most âinstitutionalâ; you could also use GUIX_PACKAGE_PATH or -L or ./pre-inst-env on a modified source checkout. <drakonis>i'm not sure if this is the kind of work that nix would strive to continue <drakonis>linj[m]: regarding the hardening options, i don't think shepherd offers any of these out of the box, so you'd have to implement them <pinoaffe>for me one of the decisive reasons that made me go for guix instead of nix was that I didn't like the fact that nix had it's own purpose-built language for configuration rather than an embedded dsl in a general purpose language <pinoaffe>also guix seemed "cleaner" in many regards <drakonis>however, having a way to interop is far more beneficial to nix than to anyone else, because it will inevitably lead to fixing nix's internals <ericson2314>drakonis: more beneficial to Nix than Guix, or Nix than Nix rewrite? <drakonis>its unquestionably beneficial to nix than guix to have it <linj[m]>drakonis: that sounds beyond my capabilities <ericson2314>(re nix using Haskell instead) Yes, I would like to see a typed nixpkgs etc. HNix we did mess around with type checker but that is cart before hourse <ericson2314>drakonis: I see unified store as more benefitial to Guix? <ericson2314>Less switching costs means the smaller community benefits <ericson2314>if you assume Nix and Guix users give the other stuff a try at equal rates <rekado>I donât think thereâs any evidence to support either of these claims <rekado>how would Guix benefit when people donât package things for Guix? ***noptys_ is now known as noptys
<drakonis>and it is beneficial only to nix because, again, it'll lead to its internals seeing a rewrite, but for guix? it'll end creating another noose <drakonis>even if the daemon was rewritten in scheme, it would have to follow someone else's design <drakonis>one that's bound to different principles <rekado>personally, Iâm often repulsed by the low quality of Nix packages in areas that I care about. It would be terrible if people just gave up on packaging things well just because thereâs a nix package where someone installs a binary and runs patchelf on it. <drakonis>plus there's the ways in which guix diverges from nix <drakonis>and these are definitely not going to play well <ericson2314>drakonis: again, how do "scheme principles" effect the store *interfaces* <ericson2314>people should definitely continue to repackage things because you want a coherent, integrated set of packages <drakonis>that was specifically aimed at the daemon <ericson2314>so you can in fact do the sexpr database you mentioned <rekado>whatâs the point of reusing the same daemon protocol? And losing the ability to change it whenever we want to? <ericson2314>is this "un schemy"? think it is pretty orthogonal to schemey-ness! <ericson2314>rekado: you can still have a guix-only daemon protocol <ericson2314>implementing a shared standard doesn't mean you can't implement it in other ways! <ericson2314>it is just ensuring there is some lowest common denominator in common <drakonis>in a hypothetical daemon rewrite, i'd have multiple store implementations <ericson2314>right, so they need to have an interface in common right? <ericson2314>I just mena if you want to swap out the store implemenation and keep the rest of guix the same, you need some sort of interfae <danisanti>drakonis: how to download guix with hurd image? <ericson2314>right so the analogy is that Linux and Hurd have some posix in common <drakonis>i can certainly implement an shared interface between stores <ericson2314>of course they are both free to have their own special sause too, but if there is no compat at all, how will people ever switch from linux to hurd? <drakonis>but still have a code path that has an entirely different approach to it <ericson2314>that is the goal, same interface different everything else! <danisanti>Cairn: thanks. that is a virtual image. is there a non-virtual image, or is guix+hurd still not good for production? <drakonis>hurd itself has very limited hardware support <drakonis>as for how guix would benefit from it, rewriting to scheme and retaining the existing store code plus a different and experimental store backend for this unified api <drakonis>guix has a lot of code that assumes the existing daemon <drakonis>as i said earlier, i'm considering throwing out a lot of code <drakonis>it generates aterm files and sends rpc to it <ericson2314>that is a nice benefit of CA derivations --- the drv hashing doesn't matter nearly as much because all the store paths are content-addressed <apteryx>do people have experience using Guix from the host in a container? <rekado>danisanti: whether itâs good enough for âproductionâ depends a lot on what you want to do with it. For most purposes it will probably not win in a direct comparison with Linux. <drakonis>basically, guile opens a port (the scheme kind) that communicates with the daemon and does what it needs <drakonis>this is why the daemon is such a skeleton at this point <drakonis>most of the heavy lifting is done on the guile side <rekado>apteryx: a process in the container talking to the daemon on the host (or a different container)? <apteryx>ideally with the 'guix' command on PATH <apteryx>e.g., Bash from a Docker container able to run guix commands normally <rekado>no idea about Docker, but there are different ways to get there <rekado>you can set up networking so that the container has an IP â then it can talk to the daemon over TCP <rekado>or you could share the daemonâs socket file and talk to that <apteryx>rekado: talk to the daemon over TCP: the daemon supports that? <drakonis>ericson2314: guix generates minified scheme for build definitions <drakonis>containing all store paths and build instructions <drakonis>it does avoid bash wherever possible, yeah. <drakonis>also, i'd really like to change the directory structure for the store at some point <drakonis>we're no longer at the early 2000s where paths had to be extremely short <drakonis>ericson2314: by the way, what you asked is called g-exps <drakonis>the minified scheme is just that everything is in a single line for saving space <drakonis>check the publications, they might shed some light <rekado>apteryx: yes, the daemon lets you talk over TCP <rekado>apteryx: itâs what we usually do in HPC installations <rekado>apteryx: see GUIX_DAEMON_SOCKET in the manual <drakonis>the second paper is closer to how it works now <ericson2314>all the papers seem to want to hide the aterm cause its ugly <rekado>do we even have an aterm packageâŚ? I donât see it. <drakonis>if i remember correctly, there's some minor incompatibilities with aterm now? <drakonis>it can be on a vm or container, i'm not judging <drakonis>also you can't install it with the script because gnupg is patched somewhere along the way <Dylan[m]>some stuff is a bit broken, but I'll fix it (when I get the time) <ericson2314>drakonis: `nix --extra-experimental-features nix-command store add-file asdf.drv <ericson2314>error: path '/gnu/store/lwkyh4hs4sch32d588vgah77i4l1mnhq-guix-package-cache' is not in the Nix store` <ericson2314>I am not sure if `add-file` is even supposed to work <ericson2314>but I am also not sure if any of our commands have really nailed down semantics lol <drakonis>cant even use nix 3.0's shell in shebangs <ericson2314>so the scheme from the gexp goes in "guix properties" oK <drakonis>cant blame ludo for not going into the nitty gritty of aterm, its bad... <apteryx>nckx: you should be able to login on most of the build machines, the redeploy seems to have finished <faust>just have a question, i use geiser in emacs to interect with guile <faust>   repl. but i have poore errors report <faust>is it possible to improve guile errors report? <apteryx>rekado: for your information, "docker run -it -v /var/guix/daemon-socket/socket:/var/guix/daemon-socket/socket -v /gnu:/gnu -v $(command -v guix):/usr/bin/guix debian" works <apteryx>I can 'guix install hello' from there <apteryx>ah, "Git error: the SSL certificate is invalid." on 'guix time-machine' <apteryx>guix install openssl was needed for SSL_CERT_DIR <apteryx>yes; I figured I can share the host one, if it's already setup there: "docker run -it -v /var/guix/daemon-socket/socket:/var/guix/daemon-socket/socket -v /gnu:/gnu -v $(command -v guix):/usr/bin/guix -v $SSL_CERT_DIR:$SSL_CERT_DIR -e SSL_CERT_DIR -v $PWD:$PWD debian" <Cairn>So I'm trying to update a package's input list to match the new style. What would `("jdk" ,icedtea "jdk")` turn into? <Cairn>So is "jdk" an output from the package "icedtea"? <Cairn>What does the first "jdk" mean in the original line? <podiki[m]>in the old style it was ("name" package "output") I believe <rekado>Cairn: the first string is just a label <podiki[m]>but anyway, key point is you want the jdk output of icedtea <rekado>it allows one to (assoc-ref inputs the-label) and get the associated package <Cairn>Would this look correct then? `(inputs (list zlib (,icedtea "jdk") qtbase))`? <podiki[m]>you need the ` for icedtea, so `(,icedtea "jdk") <podiki[m]>bah, on matrix you won't see, but it is backtick, then (,icedtea "jdk") <nckx>apteryx: Wonderful, I hope never to need it. Thanks! <nckx>Matrix eats backticks? Great news for a lisp support channel. <podiki[m]>well if you have two it makes it a verbatim/code format <podiki[m]>`this will look like monospaced code` in matrix <Cairn>How would you specify a version in the new style there? Like if I need to make sure qtbase is from version 5...? <nckx>Cairn: that didn't change, variables are still variables. <Cairn>nckx: Single backticks are inline. Triple backticks are code blocks. <podiki[m]>```testing a `(,pkgname "output") code with a ` ``` <nckx>Ey, intern Jim, you do that homework we asked you to research which characters ain't commonly used in programmin' languagees? <nckx>Uh, yeah, of course, sure. <Cairn>Haha, markdown doesn't seem to care about that much <Cairn>I mean, it uses _ and * and whatever else <nckx>Cairn: which means it's still rather arbitrary. Foo version two might be foo-2, or just foo, even if foo-1 and/or foo-3 exist. <nckx>Cairn: True. Expecting anything from Markdown is always a mistake. <Cairn>So in my package list, I still need to just change "qtbase" to "qtbase-5" and trust in the variables or something? <podiki[m]>the variable will evaluate to a unique package <podiki[m]>"trust but verify" or something like that :) <Cairn>But it's not a package of sorts? Like when I do `guix search qtbase-5` it doesn't show up? <gabber>guix search looks for a package *name*, not a variable name <podiki[m]>yes, it is a little confusing at first, but when doing package defs and such, the variables are what you will use <Cairn>My confusion has barely started. I haven't even dived into the (arguments) expression yet... <yuu[m]><ericson2314> "then why have packages in with..." <- see point two https://news.ycombinator.com/item?id=16491797 i remember reading another writeup on this; can't find it rn. but it's basically because packages are 1st class citzens since guile is an actual language that makes that feasible. and iirc easier to navigate the same repo since everything is guile, ... <ericson2314>yuu: I don't think "first class" means anything in this context <ericson2314>Guix having packages in the same repo feels to me like putting GCC and Linux in the same repo <yuu[m]><nckx> "I'm not as familiar with Nix..." <- nckx: not so much different tbh, I was surprised they have similarities. probably Nix Flakes were based on Guix channels and manifest to some extent. Guix channels/manifest just doesn't seems as flexible to me in regards e.g. arbitrary inputs <yuu[m]>John Ericson: i'm not saying it is good. that's just what i read on this. if i can find the other link which i think ludovic wrote i'll send it to you <nckx>ericson2314: It's like putting Linux and all its drivers in the same repository, which they do. <nckx>Guile is not part of Guix đ <nckx>yuu[m]: What kind of arbitrary inputs are we talking about here? <yuu[m]>nckx: afaik channels only allow to depend on other channels, not on arbitrary files, git repos, ... while flakes allows that <ericson2314>Yeah to be clear I'm not mad about packages in the same repo <nckx>Yes, channels are the unit of composition between⌠what should we call them, sub-projects? <ericson2314>I wouldn't do it that way, but if guix wants to do it that way it's fine <nckx>I don't think there's anything stopping you from eval'ing a random file you got over HTTP, apart from maintainability and maybe common sense. <ericson2314>To me, it boils down to whether using a completely different package set with guix the tool is a supported use case <ericson2314>With Nix, it is supposed to be, but there are a few stupid layer violations where it assumes Nixpkgs <nckx>Sure, but it's not a tool. It's a library. The CLI is just a small appendage. <ericson2314>drakonis: was saying the C++ nix is always in a separate process, never no daemon? <ericson2314>(or well never in-process, how the external process is managed as daemon vs something else is separate) <drakonis>using scheme made it possible to have a library first approach *nckx AFK, happy to leave such a bustling channel. <yuu[m]><ericson2314> "I thought Nix was good, but then..." <- John Ericson: you mean inputs, outputs in same place? and outputs basically being where everything else is specified? <ericson2314>i mean tight coupling between eval cache, flakes, and nix CLI <ericson2314>we can decouple them without any breaking changes, and it should have been written that decoupled way from day 1 <cwebber>ericson2314: glad to hear you liked the brainy / goblins stuff <yuu[m]>John Ericson: you probably mean in the source code github.com/nixos/nix, not in functionality per se? <ericson2314>but today's implementation informs tomorrow's interfaces so who knows... <yuu[m]>John Ericson: although i'm not familiar with nix's source, i seem to sympathize in that case. also it is not the first time i see you criticizing flakes ("Our community is in limbo as in waste-of-time projects like Flakes") and until now I could never see your actual point; i suggest if you come up with that again, make it clear that is about the repo/source code, and not functionality per se if that's the case. ***LispyLights is now known as Aurora_v_kosmose
<cizra>1. Could I get a confirm/deny on Guix System's support of LUKS-encrypted root? The manual describes it as something straightforward, yet my system (BTRFS on LUKS2 on disk, no LVM) confuses the bootloader. Perhaps the LUKS2 module is missing from GRUB? <cizra>2. does Guix decrypt LUKS2-encrypted root a) using Grub, or b) is it decrypted by the initrd? Or c) both? If a, how is the decrypted filesystem passed to the kernel? If c, does this mean I need to enter passphrase twice? ***ChanServ sets mode: +o litharge
***litharge sets mode: -bo *!*clararuss@* litharge
<nckx>(1) Can't say, I use the simplest of encrypted roots: https://paste.debian.net/plainh/1d197b96 (2) âYesâ â both. There's no key passing protocol nor is the key stored in the initrd. You enter the passphrase twice on boot. <nckx>Bugs aside, encrypted root is absolutely a âsupported featureâ. <cizra>nckx: Thanks. Is there a reason why you have targets in plural and using a singleton list? The manual teaches to use singular form. <cizra>And yeah, lilyp, I have luks2 (the manual didn't have any opinion on it) and it doesn't decrypt in GRUB. *jonsger[m] uses XFS on LUKS but with EFI boot :) <cizra>Huh. I thought it'd be unstable or something. <unmatched-paren>`guix pull` fetches the latest master, which matches with the latest devel manual <cizra>Yeah, it seems my LUKS2 is not good enough for GRUB... # cryptsetup luksDump /dev/sdb2 | grep PBKDF says argon2id - I wonder if I can change it without recreating the FS... <examors_>Yeah, you can add a new passphrase using cryptsetup with --pbkdf=pbkdf2, and then remove the old one <cizra>Ayup, I can. Guix System, here I come! <cizra>Why not redownload the installer image too, while we're at it. Thanks for the tips, folks. Tho I'd prefer to not type the password twice... On other distros, the kernel and initrd are unencrypted in ESP (tho signed for Secure Boot) and decryption is done by initrd. I wonder if I could cheat the Guix system by moving the kernel/initrd out, and just have Guix decrypt the FS once? <lilyp>unmatched-paren: you could probably still use the 1.0 disk as long as you run guix pull after starting the cow-store :) <lilyp>cizra: I'mma give you the tip that I give everyone: Start with the smallest working system and add enhancements later. <lilyp>It's much simpler to get what you want once you have a running Guix System <acrow>vagrantc: directory exclusions have been added to the debian-copyrighter. <lilyp>though in the particular alley of cheating the crypto no one really worked that out yet, so contributions are definitely welcome :) <cizra>lilyp: Definitely! I can enter the PW twice until I get the basics to run fine. <apteryx>cizra: you can, not supported at the config level yet <nckx>cizra: The manual teaches to use a list, maybe you're using an old manual. <nckx>Singular is still supported for backwards compatibility, though, so it shouldn't be the cause of your troubles. <nckx>As you were told in the meantime. <nckx>I think we happen to support a subset of LUKS2 with an uncommon (non-default) KDF. <cizra>yep. Thanks for the pointers! I'm installing now, see how it goes. <cizra>nckx: Not that I care much, as long as either works :) <nckx>I really need to get that link swapped. <vagrantc>given that presumably everyone uses guix pull to pull to a "current" generation, maybe the non-devel manyal shouldn't even be published? <apteryx>nckx: seems our removal of mono will happen just in time for microsoft+canonical rejoicing with their nonfree dotnet6 <nckx>I got kinda stuck on the part where I add a big spooky âthis shit be oldâ banner to the 1.3 manual. <nckx>So ânot hosting it at allâ is tempting but probably not going to fly. <nckx>apteryx: (1) Wait, (2) wat. <nckx>We should take advantage of the news cycle and blog post it. <nckx>âGuix waves goodbye to legacy .NET technology.â *vagrantc thought mono was a free implementation of .net <vagrantc>but happy to never had to have to mess with much of any of it <unmatched-paren>but we're removing it because it includes loads of prebuilt binaries, iiuc <podiki[m]>the "stable/old" manual is probably only useful to match to an installer version for reference outside of install env <nckx>Those binaries are reportedly buildable from source but nobody ever bothered, and yep, so old (2016 IIRC) that nobody ever will. <nckx>Please use a pastebin, such as the one in the topic, that's not just a ploy to push wasm on people. <cwebber>has anyone tried setting up goaccess to monitor logs on Guix <yuu[m]>nckx: https://paste.debian.net/ `413 Request Entity Too Large` for error log, and Thanks to some spammers you need to provide at least 2 linebreaks for drv. what should i use instead? <nckx>yuu[m]: Oh, I assumed you were pasting the error message. The .drv is pretty useless. <nckx>My bad, I missed that you explicitly asked for it. <nckx>error: build of `/gnu/store/9pmr70q6614fgswgs0bc28cxggs0gjds-grub.cfg.drv' failed <nckx>â this is not the full error, there would have been more. <nckx>That more is what we'd need to start helping. <nckx>It's possible that I missed it in the sea of different pastebins! <nckx>yuu[m]: Not related, but I'm not sure what the âcarâ comment refers to. <nckx>Is this --debug= or something? <nckx>I should have been more specific, sorry. Your âguix systemâ command (without --debug= for both our sanities) should print something like âView error log atâ, followed by a file name, usually ending in .gz. Is that so? <yuu[m]>nckx: ah i forgot to remove that. it's because i was (list) in the let to not need `(dependencies (list ..` but just `(dependencies`. but that didn't make sense. your solution worked, but then i had another issue and just commented dependencies for now <nckx>I know that should be sudo grep, sorry, typo. <nckx>And frankly, br-abnt2 does indeed not sound correct. <nckx>Should that be "br" "abnt2" perhaps? <nckx>(Two strings, the second is the âvariantâ.) <nckx>yuu[m]: Eyy, I see you commented that out. Why? Different error? <nckx>grep abnt2 $(guix build xkeyboard-config)/share/X11/xkb/symbols/br says it should work. <nckx>tricon, apteryx: Just yesterday I got trapped in a âM$ has done so much for free software, it's unfair how they are treated, they've changedâ conversation. That would have been a nice link to drop whilst I made my escape. <tricon>nckx: yeah, i need to get all of my stuff off of GitHub. i've been lazy. please don't send me to the rack! <apteryx>so typical; exactly how MS would like them to be perceived. <lilyp>That link mentions unfortunately little about the bootstrap nightmare though. <jackhill>lilyp: re: gst-plugins/selection I'm not sure, I haven't looked at it lately. I'll give it a try and report back in the ticket. <lilyp>No rush, I'm just cleaning up my old bugs ;) <podiki[m]>anything else come up for the emacs with native-comp patches? <lilyp>there's a v2 for the build-system patch, but for now it's just trying out your configuration and reporting failures <lilyp>I'm not a person to rush changes and fwiw I haven't tried out my own yet â will probably do so this weekend after some tempel integrations to my init <podiki[m]>i have not tried tempel (or really yassnippet beyond those for guix commit messages) <shcv[m]>I'm having trouble getting channels to "stick"; I create the appropriate channels.scm file, run `guix pull` and it updates both channels, but then running describe afterward only shows the main guix channel. Any ideas? <rekado>shcv[m]: did you âguix install guixâ? <rekado>what does âtype guixâ tell you? <yuu[m]>how to disable guix system init mounting tmpfs on /mnt/tmp? couldn't find anything on the docs <yuu[m]>(i'm getting OOM even with 4GiB) <shcv[m]>rekado: `type guix` points to .guix-home/profile/guix; but I have a `(simple-service 'variant-packages-service home-channels-service-type (list (channel ...)))` in my home config that should add the channel... <shcv[m]>I also ran into that problem on another machine that wasn't using guix home, but it's broken at the moment <yuu[m]>actually it doesn't seem to tmpfs on /mnt/tmp, but on /tmp and /dev/shm. but still oom `ERROR: In procedure apply-smob/1:` `ERROR: In procedure scm_flush: No space left on device` `guix system: error: cannot close compressed log file (gzip error = -1)` <yuu[m]>hm not sure if my premises are correct. `2.4G /gnu/store`. `/dev/sda2 29G 2.1G 27G 8% /mnt` (27 avail, 2.1 used) <vagrantc>shcv[m]: gugix install guix will perpetually download you to an older version of guix :) <yuu[m]>oh no `none 2.0G 1.8G 159M 92% /` <yuu[m]>so indeed memory. it's feeling up /gnu/store <yuu[m]>this is actually 4GiB, but guess guix auto assigns half of that, so 2GiB <yuu[m]>how much memory does guix system init needs? <muradm>apteryx: i'm giving up on (gnu services configuration) <muradm>while it tries to make less lines of code they become less and less readable <nckx>yuu[m]: Did you start cow-store pointing to a mounted drive? <nckx>It should prevent exactly this situation (RAM drive filling up with new store items that should eventually end up on /mnt anyway). <nckx>yuu[m]: You could create & swapon a swap file on /mnt and then âmount -o remount,size=nG /tmpâ if you need to get out of the situation without rebooting. <nckx>Oh, it's /. That might not work because âbusyâ (which is stupid). Never mind then. <wnklmnn>Hi I'm trying to get gitk added to my guix home configuration. I've seen that gitk is in the 'gui' output. trying to add (list git "gui") or (specification->package+outputs "git:gui") to the packages list does not seem to result in gik being available. the regular git command still works fine. is there anything i'm missing? <rekado>shcv[m]: you should not have guix at .guix-home/profile/guix <rekado>it should be .config/guix/current/bin/guix <rekado>thatâs the one controlled by âguix pullâ <shcv[m]>then how did it get that way? I didn't change that... <rekado>depends on your home configuration and on the way you set up env vars <shcv[m]>nevermind; apparently guix was in the package list it was installing, probably from the initially generated configuration <shcv[m]>I'll remove the specification from the package list, reconfigure, and see if it gets any better